Created attachment 25965 [details] testcase No mount per-sb counters (freeblocks/freeinodes/dir and etc) are initialized before journal was replayed. But in fact if journal wasn't empty statistics will be probably changed after journal replay. This result in per-sb counter inconsistency which result in incorrect delalloc reservation. See testcase. This is long standing bug at least from 2.6.12 where the linus's tree starts i (was too lazy to dig in to old-git tree). But it case of ext3 this result only in incorrect numbers from statfs() The fix is simple, we just have to move counter initialisation after journal_reply. I've open this bug only as testcase storage.
dmesg after testcase check kjournald2 starting: pid 1310, dev sdb1:8, commit interval 5 seconds EXT4-fs (sdb1): internal journal on sdb1:8 EXT4-fs (sdb1): delayed allocation enabled EXT4-fs: file extents enabled EXT4-fs: mballoc enabled EXT4-fs (sdb1): recovery complete EXT4-fs (sdb1): mounted filesystem with ordered data mode mpage_da_map_blocks block allocation failed for inode 14 at logical offset 4667 with max blocks 5192 with error -28 This should not happen.!! Data will be lost Total free blocks count 0 Free/Dirty block details free_blocks=7222 dirty_blocks=5209 Block reservation details i_reserved_data_blocks=5192 i_reserved_meta_blocks=17
proposed patch http://patchwork.ozlabs.org/patch/49963/
(In reply to comment #2) > proposed patch http://patchwork.ozlabs.org/patch/49963/ Opps, the patch attached is wrong in case of no_journal mode. Will send new version soon.
Updated version of the fix posted here. http://patchwork.ozlabs.org/patch/49989/
Patch : http://patchwork.ozlabs.org/patch/49989/ Handled-By : Dmitry Monakhov <dmonakhov@openvz.org>
Fixed by commit 84061e07c5fbbbf9dc8aef8fb750fc3a2dfc31f3 .