Hello Daniel, "Daniel Alder": > There were two problems: > > 1) au_add_till_max returns ULLONG_MAX if b==0 > > Reason: in this case, a is not bigger then old but equal. This is the reason > for the very big values which confuse df.
Exactly. This must be my bone-head bug. > 2) If aufs is mounted in sum mode, but the source file systems have different > block sizes, the result of the statfs might not be useable. Exactly again. This must be my bone-head bug too. But I think there are two approaches here. - keep the original (the topmost one) bsize. - select the biggest one as bsize and re-calculate blocks, bfree and bavail. If we choose the second, the multiply will be unnecessary and we don't have to worry about the overflow, right? For example, if the biggest bsize is 4K and there is 1K bsize branch, then we will right-shift the 1K blocks value by 2 bits and add it to the sum. So what should we do when the bsize is a strange number like 1234 bytes. Hmm, I don't want to support such strange fs, but what will we do if it happens? Simply ignore it? I may agree with it. > It is my first kernel-code work. I think the changes in au_statfs_sum are > quite Good job. If you have a patch for somewhere else in kernel, then I'd suggest you to post it to LKML without hesitating. By the way, I could apply the patches 2/3 and 3/3 cleanly, but 1/3. I am afraid 1/3 was manually edited. People may dislike such patch. J. R. Okajima ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/
