Is this a ZFS bug, a pacman bug, or working as expected? statp->f_bsize = 128KB leads to over-estimation of free space required

[digitalsignalperson]

Provisioning an arch linux system in a VM:

• root dataset has 14.1G avail reported by zfs list
• doing a pacman -S with everything already downloaded and in cache, pacman reports "Net Upgrade Size: 4786.55 MiB" and then

(763/763) checking available disk space                                                  [####################################################] 100%
error: Partition / too full: 172351 blocks needed, 115656 blocks free
error: not enough free disk space
error: failed to commit transaction (not enough free disk space)
Errors occurred, no packages were upgraded.

• I can query the available blocks in the same was as pacman with statvfs.h and confirm those numbers

Mountpoint: /
fsInfo.f_blocks: 126059
fsInfo.f_bfree: 115656
fsInfo.f_bavail: 115656
fsInfo.f_bsize: 131072

So the block size is reported as 131072=128KB, and 115656 x 128KB = 14.1G as expected. Yet pacman is asking for 172351 blocks, or a whopping 21GB for a "Net Upgrade Size: 4786.55 MiB"

So what's the problem...

pacman/lib/libalpm/diskspace.c calculate_installed_size() does this

for(i = 0; i < filelist->count; i++) {
    ...
    /* the addition of (divisor - 1) performs ceil() with integer division */
    install_size = (file->size + mp->fsp.f_bsize - 1) / mp->fsp.f_bsize;
    mp->blocks_needed += install_size;

So it's calculating the number of blocks it needs by rounding the size of every file in every package up to 128KB... I think this is the issue leading to a huge over-estimation of the required disk space.

zfs sets statp->f_bsize = zfsvfs->z_max_blksz; to the max block size here: https://github.com/openzfs/zfs/blob/cae502c17576694721d290c2506880d0caa872c7/module/os/linux/zfs/zfs_vfsops.c#L1114C39-L1114C39

This was another reference I found: #112

My pool uses ashift=12 so is the min block size actually 4096 bytes?

[digitalsignalperson]

The quick and dirty work-around I just did was to change my big

pacman -S --noconfirm --needed $PACKAGES

to

for pkg in $PACKAGES; do
    pacman -S --noconfirm --needed $pkg
done

which succeeded to split things up enough to reduce the over-estimation error.
After completion of this, zfs list reports 11.0G available - only 3GB actually used.

[rincebrain]

If your pool has ashift=12, then modulo special cases like embedded_data, yes, 4k is the smallest anything is going to use for a record.

[IvanVolosyuk]

It seems the question is about stat() call reporting the record size for the value of stat.st_blksize. So, for the record size of 128k the block size will be the same. That causes pacman to wildly overestimate the total size required for gazillion of small files. For the purpose of this calculation it would be more reasonable to use record size = (1 << ashift). I wonder what are the other use cases, which better work if we report block size equal to record size. BTW, this calculation will not account for compression and dedup FWIW.

…

On Tue, Aug 22, 2023 at 10:42 PM Rich Ercolani ***@***.***> wrote: If your pool has ashift=12, then modulo special cases like embedded_data, yes, 4k is the smallest anything is going to use for a record. — Reply to this email directly, view it on GitHub <#15198 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABXQ6HJQCV5X3WS5HLE4TIDXWSSMPANCNFSM6AAAAAA3ZTSJM4> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[amotin]

Record size may be useful if application need to optimize some operation that are only possible/efficient on that basis, such as hole punching/reporting, copy_file_range()&co, random accesses, etc.

[rincebrain]

I mean, 1 << ashift wouldn't work on pools with mixed ashift vdevs anyway, and neither would anything that tried to pick the lowest or highest value depending on what it was using it for.

[digitalsignalperson]

Looking for some definitions of f_frsize and f_bsize

https://stackoverflow.com/questions/54823541/what-do-f-bsize-and-f-frsize-in-struct-statvfs-stand-for

Just cite the The Linux Programming Interface (Page 276) as a supplement:

For most Linux file systems, the values of f_bsize and f_frsize are the same. However, some file systems support the notion of block fragments, which can be used to allocate a smaller unit of storage at the end of the file if a full block is not required. This avoids the waste of space that would otherwise occur if a full block was allocated. On such file systems, f_frsize is the size of a fragment, and f_bsize is the size of a whole block. (The notion of fragments in UNIX file systems first appeared in the early 1980s with the 4.2BSD Fast File System, described in [McKusick et al., 1984].)

And interestingly in openzfs history back in 2011: #112 (comment)

Increase fragment size to block size

The underlying storage pool actually uses multiple block
size. Under Solaris frsize (fragment size) is reported as
the smallest block size we support, and bsize (block size)
as the filesystem's maximum block size. Unfortunately,
under Linux the fragment size and block size are often used
interchangeably. Thus we are forced to report both of them
as the filesystem's maximum block size.

Closed by 05ff35c

Is the "Thus we are forced to report both of them as the filesystem's maximum block size." still valid?

Maybe this is a possible two-part solution:

• openzfs changes to set f_frsize = 1 << ashift so it exposes the fragment size as the smallest supported block size
• pacman changes to use f_frsize in it's calculation and not f_bsize

Or maybe pacman just needs some option that can be passed to override the size calculation or specify the block size somehow.

[digitalsignalperson]

Looks like there's already a pacman bug open for this (not updated since 2016), and with a workaround described: https://bugs.archlinux.org/task/45070#comment142712

Workaround for this issue is disable diskspace check:

sed -i -e 's/CheckSpace/#CheckSpace/' /etc/pacman.conf

[rincebrain]

I gave up trying to read the modern KDE code equivalent, but it seems to do nothing like that kind of math any more, while the deprecated library call still works the same way, so if things are still using that, the same reasons apply.

I still think reporting either the smallest or largest minimum there is going to break people sometimes though.