[pacman-dev] libalpm fails on a filesystem with a large blocksize
Hello,
''pacman --debug --root dir -S util-linux'' fails on a 2 GB NFS (1,9 GB free): "Partition /root/dir too full: 12385 blocks needed, 3802 blocks free"
statvfs() reports f_bsize = 524288, f_bfree = 3855, so the "blocks free" estimate is correct, taking the cushion into account.
A little debugging shows that the "blocks needed" overestimate comes from calculate_installed_size @ lib/libalpm/diskspace.c which, basically, rounds every file's size up to a multiple of the block size. In my case, having a huge block size, it is indeed summing 1 block per file.
Is it possible to work around this problem, and how?
Thanks
On 13/06/15 23:05, Astro Xe wrote:
Hello,
''pacman --debug --root dir -S util-linux'' fails on a 2 GB NFS (1,9 GB free): "Partition /root/dir too full: 12385 blocks needed, 3802 blocks free"
statvfs() reports f_bsize = 524288, f_bfree = 3855, so the "blocks free" estimate is correct, taking the cushion into account.
A little debugging shows that the "blocks needed" overestimate comes from calculate_installed_size @ lib/libalpm/diskspace.c which, basically, rounds every file's size up to a multiple of the block size. In my case, having a huge block size, it is indeed summing 1 block per file.
Is it possible to work around this problem, and how?
Not that I know of. I am fairly sure that only one file can be stored in one block.
Allan
f_bsize appears to be linked to NFS's wsize parameter. You should be able to specify a lower value for that in the mount options on the NFS client.
Ideally, you'd set wsize to the server's physical block size. Higher values might result in (much) better write performance but the free space calculation will no longer be accurate.
Perhaps there's a clean way to figure out the correct block size for NFS mounts, but I'm going with what pacman currently does, statvfs(2).
Thanks! Changing rsize/wsize removes the disk space check error.
For posterity, including myself:
Indeed, from what I could gather from the archived discussions: http://lkml.iu.edu/hypermail/linux/kernel/0310.1/0392.html (and the subsequent message by Linus) http://h30499.www3.hp.com/t5/LVM-and-VxVM/definition-of-f-bsize-vs-f-frsize/... it seems that f_bsize originally meant "high-level block size for efficient I/O" which explains why it's linked to rsize/wsize.
I was about to suggest f_frsize ("fragment size") as an alternative, but a quick test reveals that it has the same value as f_bsize, on that very same machine/NFS; which confirms Linus' suggestion for "optimal block size everywhere" in the discussion linked above. BTW I have checked the "one file per block" rule by successfully creating more than 10000 files from that same client/NFS, so it seems that this result is somehow allowed by the abstraction.
Thanks again
participants (3)
-
Allan McRae
-
Astro Xe
-
Evangelos Foutras