Hi, > I think I have found a regression introduced by commit 9d0be50 "ext4: > Calculate metadata requirements more accurately". Thanks for report! > I am using ext4 on a NFSv4 server running unpatched kernel 2.6.33.3. > The client is currently running unpatch 2.6.33.3, although I also saw > the problem with the client running 2.6.32.10. > > The output from 'df' on the client varies wildly in the presence of > certain writes. I have not pinned down an exact write pattern that > causes it, but I do have an application that causes it fairly reliably. > When the bug happens, I see swings like this: > > Sun May 9 23:04:58 2010 blocks=961173888 available=28183168 > Sun May 9 23:04:59 2010 blocks=961173888 available=12823424 > Sun May 9 23:05:00 2010 blocks=961173888 available=28183040 > > (produced by a script that checks statvfs output every second; units are > kB, df output is effectively identical) Hmm, I'm not seeing anything obviously wrong with that patch but apparently the number of blocks reserved for delayed allocation is miscomputed by a lot... Is your ext4 filesystem create from scratch or converted from ext3? Is your application using lots of different files or rather a couple of small ones? Anyways a reproducing program would be the best in this case... Honza -- Jan Kara <jack@xxxxxxx> SuSE CR Labs -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
