Hi J. R. Okajima > 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.
As far as I know bsize is defined as a power of 2, so 1234 is not possible. For your understanding, why multiplication is necessary: Layer 0: 7 blocks of bsize 131072 Layer 1: 5 blocks of bsize 4096 The sum is either (7*131072/131072 + 5*4096/131072 + ...) if reported bsize is 131072 (7*131072/4096 + 5*4096/4096 + ...) if reported bsize is 4096 We can also do the division at the end, but the multiplication is necessary in every step. If we do the division at the end, the u64 has to store the full size in the unit byte. In this case, chances are big (at least bigger) to have an overflow. there is a third variant: 131072 = 100000000000000000b = 2^17 4096 = 1000000000000b = 2^12 reported bsize=2^12 (the smaller for better granularity) (7<<(17-12) + 5<<(12-12) + ...) >> 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. 1/3 was not manually edited. Why do you think it is? I used quilt according to a tutorial. unfortunately, I got a bounce message from the Mail list. That's the reason why I sent it twice (in different formats). Daniel Alder ------------------------------------------------------------------------------ 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/
