uvol: add ext4 partition support for SSD's on x86

[pprindeville]

Maintainer: @dangowrt Environment: x86_64, generic, HEAD

Description:

On x86 and x86_64 machines, it's not uncommon to have root residing on SSDs or NVMe. In such cases, an ext4 filesystem would make sense.

[dangowrt]

uvol is a storage volume manager abstraction working on top of LVM2 for block devices and UBI for NAND. The filesystem type of created r/w volumes depends on the storage media and size:

• On NAND/UBI, only UBIFS can be used
• Small volumes on block devices use Ext4
• Larger volumes on block devices use F2FS

Using uvol for the root filesystem itself is neither intended nor possible.

[pprindeville]

Sorry, I wasn't saying that the root was ext4, I was saying that the remaining space on the same device as the root could be ext4.

[dangowrt]

In this case just install uvol and autopart and add this to your boot script:

[ $(uvol free) -gt 0 ] && {
  uvol create data $(uvol free) rw
  uvol up data
}

You may of course then edit /etc/config/fstab to use a different mount point.

[pprindeville]

Having issues with sfdisk, in particular failures in get_free_area():

1. ${size%%.*M} should be ${size%%M} since just the M is the suffix.
2. start=$start, size=$((end - start)) should be $((end - start + 1)) shouldn't it?

root@pigpen:~# sfdisk -q -F /dev/vda 
 Start     End Sectors  Size
505856 1009667  503812  246M
root@pigpen:~# echo $((1009667 - 505856 + 1))
503812
root@pigpen:~# 

Since end is the number of the last sector. Just as [0..5] has 6 elements in it.

But this opens the question, why recompute the size rather than using the 3rd (Sectors) column?

[pprindeville]

Ah, I see. The bug came in with this commit. If you have an integral size, that doesn't work.

[pprindeville]

Fix proposed in PR #20343.

[pprindeville]

Okay, different issue. If we're using MBR, if we're using extended partitions, then (1) the extended partition needs to be grown, and (2) the new partition needs to be added inside the extended partition. The current logic doesn't handle that.

[dangowrt]

sfdisk transparently supports GPT, no additional changes are needed for that, see manpage:

Since version 2.26 sfdisk supports MBR (DOS), GPT, SUN and SGI disk
labels, but no longer provides any functionality for CHS
(Cylinder-Head-Sector) addressing. CHS has never been important for
Linux, and this addressing concept does not make any sense for new
devices.
...
util-linux 2.38.1                 2022-08-04                         SFDISK(8)

You are right, however, that things become more tricky if we want to support MBR extended partition (I didn't need that yet).