sys-fs/unionfs-1.0.8-r2, which I just emerged and otherwises seems to be a wonderfully useful filesystem, seems to report used/available in df as 2 * the sum of all devices containing the unioned dirs. There appear, to me, to be 2 rational answers, which I list in order of usefulness and inversely in cost of computation: 1) available from the devices containing the unioned dirs (counting devices only once) + used by actually scanning the unioned dirs, 2) used&available from the devices carrying the unioned dirs (counting devices only once). I think of du as costly and df as cheap and choosing 1, which provided the best info, makes df costly. My personal preference, which reflects my usage and may not be the best answer, is option 2 which keeps df cheap to execute, clearly provides better info than the current implementation, and for one common case - merging disks at the root level, provides perfect info. Reproducible: Always Steps to Reproduce: 1.emerge -uva unionfs 2.mkdir /tmp/testufs{,1,2} 3.mount -t unionfs -o dirs=/tmp/testufs1:/tmp/testufs2 none /tmp/testufs Actual Results: df will show /tmp/testufs having available = 4* available of / -- weird from other experiments here this is actually 2*(available on device containing /tmp/testufs1 + available on device containing /tmp/testufs2) Expected Results: I suspect it intended to return 2 * available of / but reported 512 byte blocks instead of 1024 byte chunks (or is this a df issue?, not sure since I've never looked at the lower level stuff). In any case, I think at very least it should not count storage as available or used more than once so in my test case available should be 1, not 2, * available on /
run df through strace and see if it's a bug in df or in the kernel module ... df gets it info by stating devices ... strace -estatfs df / > /dev/null
ok, it produces strace -estatfs df /tmp > /dev/null statfs("/", {f_type="REISERFS_SUPER_MAGIC", f_bsize=4096, f_blocks=4002068, f_bfree=2194310, f_bavail=2194310, f_files=0, f_ffree=0, f_fsid={0, 0}, f_namelen=255, f_frsize=4096}) = 0 and using the mount in question gives strace -estatfs df /tmp/testufs > /dev/null statfs("/tmp/testufs", {f_type=0xf15f, f_bsize=8192, f_blocks=8004136, f_bfree=4388620, f_bavail=4388620, f_files=0, f_ffree=0, f_fsid={0, 0}, f_namelen=0, f_frsize=8192}) = 0 It seems (f_bsize=8192) * (f_blocks=8004136) / 1024^2 = 4 * df -m for / so I'm guessing df is exonerated note that the call for / gives f_bsize=4096, f_blocks=4002068 and that for /tmp/testufs gives f_bsize=8192, f_blocks=8004136 (each being 2x the value of the root call) So, I guess 2x2=4, the factor by which the answer was wrong maybe it is not double counting / at all but seeing 2x as many blocks at 2x their actual size. That would certainly account for the 4x reported difference thanks for persuing this
which means it looks like unionfs is reporting the stuff wrong right ?
I'm a bit out of my depth here, but that is my take on the data. It looks like unionfs picked 8K as the block size (it general it may unify devices with different block sizes so this seems perfectly sensible) then when converting 4K blocks to 8K blocks goofed and multiplied by 8K/4K rather than 4K/8K
Can you please report this problem upstream to http://lists.filesystems.org/mailman/listinfo/unionfs I dont think its a problem with the ebuild or with portage .. and I am not really in unionfs code so I think they can better deal with these problems.
oh, and it would be nice when you could tell me if the new version 1.0.9 works for you .. I will then do a version bump :)
Ok, I have posted a detailed bug report on the unionfs mailing list. I have also verified that 1.09 works here. So, why don't you go ahead and bump Gentoo's version to 1.09. While you are at it please add the ~amd64 keyword since I've been running unionfs on my amd64 box for a few days with no issues other than the df size issue, which I presume it also true for non amd64 systems.
The unionfs folks have acknowledged the bug and entered it into their bug tracking system. Here is their response to my bug report: Richard, You're right, there is actually a combination of two problems that need to be fixed here. First, Unionfs adds the blocksize across all the file systems, when instead it should just pick one (probably the first it comes across) and represent everything in terms of that block size. The second is that it sums the available blocks across all file systems. This normally makes sense, but if two branches are on the same file system, it will count extra blocks. I've entered this bug into our tracking system as #212. Charles
