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

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