Bug 15768
Summary: | Incorrectly calculated free blocks result in ENOSPC from writepage | ||
---|---|---|---|
Product: | File System | Reporter: | Dmitry Monakhov (dmonakhov) |
Component: | ext4 | Assignee: | fs_ext4 (fs_ext4) |
Status: | CLOSED CODE_FIX | ||
Severity: | high | CC: | dmonakhov, maciej.rutecki, rjw, tytso |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | from 2.6.11 to 2.6.33-rc4 | Subsystem: | |
Regression: | No | Bisected commit-id: | |
Bug Depends on: | |||
Bug Blocks: | 15310 | ||
Attachments: | testcase |
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 . |
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.