udiskslinuxfilesystem: Use ID_FS_SIZE for filesystems that are not known to report ID_FS_LASTBLOCK

[tbzatek]

Looking at the util-linux-2.39.1 sources only xfs, ext and btrfs probes do have support for reporting filesystem last block. There are many others however that do report filesystem size that would still be beneficial for UDisks to use.

However, for filesystems that we know the two values differ and that are proven to work fine with bd_fs_get_size(), we should still avoid using ID_FS_SIZE. Let's maintain a short internal whitelist.

---

See the previous discussion in #1114 and the feedback in #1139.

Taking vfat and ntfs as an example, the filesystem size computation looks roughly similar. For the moment it looks like a best effort. The whitelist introduced serves also a blacklist for ID_FS_SIZE for some filesystems.

Fixes #1139
Cc: @mvollmer

[vojtechtrefny]

Looks good to me.

[mvollmer]

I don't see how this fixes #1139, tbh, and I can't say whether using ID_FS_SIZE is ever correct for the Filesystem property. Are these udev properties documented somewhere?

[tbzatek]

I don't see how this fixes #1139, tbh, and I can't say whether using ID_FS_SIZE is ever correct for the Filesystem property.

So the point is, for all supported filesystems, is bd_fs_get_size() even correct / suitable for this UDisks property? Apart from the whitelist of course. As noted above, the computation for vfat and ntfs looks roughly similar. For these two this however doesn't guarantee the real filesystem border is reported. So even libblockdev mixes the two concepts together.

Some references to the libblkid implementation:

• https://bugzilla.redhat.com/show_bug.cgi?id=2064810#c6
• Add FSLASTBLOCK tag and blkid with btrfs test util-linux/util-linux#1665
• libblkid: merge FS* flags into one FSINFO util-linux/util-linux#1678
• libblkid: add FSBLOCKSIZE tag util-linux/util-linux#1698
• libblkid: add FSSIZE implementation for btrfs and ext util-linux/util-linux#1702
• libblkid: add tags list to the man util-linux/util-linux#1762

Manpage only mentions this:

- FSSIZE - size of filesystem. Note that for XFS this will return the same value
  as lsblk (without XFS's metadata), but for ext4 it will return the size with
  metadata and for BTRFS will not count overhead of RAID configuration
  (redundant data).

- FSLASTBLOCK - last fsblock/total number of fsblocks

- FSBLOCKSIZE - file system block size

This is what we want to mimic in the first place, right?

• https://github.com/lvmteam/lvm2/blob/2928891bd00bce8d880f8c3a6aec430a57c49377/lib/metadata/lv_manip.c#L6046-L6092
• https://github.com/lvmteam/lvm2/blob/2928891bd00bce8d880f8c3a6aec430a57c49377/lib/device/dev-type.c#L887-L952

So let's ask the experts @alberand and @karelzak the ultimate question:

• for filesystems that don't implement FSLASTBLOCK natively, shall we ignore FSSIZE as there are no guarantees the value represents the very last block on the device? Concerning mostly simple filesystems like vfat, exfat, ntfs and others without journal or extra metadata.

[tbzatek]

@mvollmer Out of curiosity, how does Cockpit decide on minimal shrink size now that UDisks doesn't provide such info for ntfs? cockpit-project/bots#5082 (comment)
Related to both storaged-project/libblockdev#952 and lvmteam/lvm2#123

[alberand]

So let's ask the experts @alberand and @karelzak the ultimate question:

• for filesystems that don't implement FSLASTBLOCK natively, shall we ignore FSSIZE as there are no guarantees the value represents the very last block on the device? Concerning mostly simple filesystems like vfat, exfat, ntfs and others without journal or extra metadata.

yup, FSLASTBLOCK is the very last block and FSSIZE is more like "total data blocks", but not always. For example, for FSSIZE btrfs doesn't take into account blocks used for redundant data and ext4 also counts fs metadata blocks. See comments here https://github.com/util-linux/util-linux/pull/1702/files. So, for ext4 FSLASTBLOCK would probably always correspond to FSSIZE. Looking at the code of fs's, you mention, this would be probably also true.

[tbzatek]

Thanks @alberand. This is not really reassuring so I'll ditch any use of FSSIZE now. Once libblkid gets proper support for FSLASTBLOCK for other filesystems (ntfs, vfat, etc.), UDisks will pick it up.

I've pushed just another iteration of the computation rules in the meantime, rather restricted.

[mvollmer]

Out of curiosity, how does Cockpit decide on minimal shrink size now that UDisks doesn't provide such info for ntfs?

It doesn't. Cockpit only uses the Filesystem.Size property to detect filesystems that are too small for their block devices and to allow the user to fix the situation. When resizing a block device directly in Cockpit, the Filesystem.Size property is not used.

[vojtechtrefny]

Still looks good to me.