http://bugzilla.novell.com/show_bug.cgi?id=587265
http://bugzilla.novell.com/show_bug.cgi?id=587265#c4
--- Comment #4 from Jeff Mahoney 2010-03-22 14:19:29 UTC ---
No, I'm pretty certain this patch set will fix this issue. I prefer to have bug
reporters verify the fix before declaring the issue resolved.
There were several reports against ext4 that I rolled up this test kernel for.
None of them were data integrity issues. This one isn't either. This one was an
over aggressive sanity check fixed upstream by commit
0637c6f4135f592f094207c7c21e7c0fc5557834 and then refined in several additional
commits.
For reference, the commit message for this is:
As reported in Kernel Bugzilla #14936, commit d21cd8f triggered a BUG
in the function ext4_da_update_reserve_space() found in
fs/ext4/inode.c. The root cause of this BUG() was caused by the fact
that ext4_calc_metadata_amount() can severely over-estimate how many
metadata blocks will be needed, especially when using direct
block-mapped files.
.. which is exactly this issue.
I don't have an answer for what I'd do in your situation. In my situation, I
have ext4 running on most of my nodes. My background is in file system
engineering so when I see certain types of faults I have a pretty good idea of
when they can sacrifice data integrity or not. Bugs like these don't tempt me
to revert to older file systems.
We haven't seen any data integrity issues in ext4 for a while outside of the
fsync() debacle, which is really a result of ext3 being more aggressive about
flushing to disk and application developers coming to depend on that behavior.
As far as stability goes, ext4 is no more problematic than the rest of the
kernel.
--
Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.