[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20090313071146.4B541108042@picon.linux-foundation.org>
Date: Fri, 13 Mar 2009 00:11:46 -0700 (PDT)
From: bugme-daemon@...zilla.kernel.org
To: linux-ext4@...r.kernel.org
Subject: [Bug 12821] filesystem corrupts on heavy I/O
http://bugzilla.kernel.org/show_bug.cgi?id=12821
------- Comment #14 from lucent+lkml@...il.com 2009-03-13 00:11 -------
I'm seeing a similar error with heavy read/write I/O on a 1TB ext4 volume. It's
not clear what behavior triggers the error for me. Occasionally I see the error
in dmesg...
[ 7829.004269] EXT4-fs error (device sdb1): ext4_ext_search_right: bad header
in inode #2491097: unexpected eh_depth - magic f30a, entries 78, max 340(0),
depth 1(2)
[ 7829.012197] mpage_da_map_blocks block allocation failed for inode 2491097 at
logical offset 2788227 with max blocks 7 with error -5
[ 7829.012220] This should not happen.!! Data will be lost
...and sync does not complete. It's not clear from the discussion if e2image
needs to be done before the error occurs on a clean mount, or afterward while
the system is up.
When this happens the reboot procedure does not complete, and I power cycle the
machine. After a power cycle, the journal replays and fsck completes, no
inconsistencies. The files affected by data loss are part of a BitTorrent
network download and after a Torrent data consistency check, I confirm that
data has been lost. If I leave the Torrent active downloading for more than an
hour or so, the ext4 errors occur.
So, "me too" with linux-image-2.6.28-8-generic 2.6.28-8-generic #28-Ubuntu SMP
Thu Mar 5 21:49:36 UTC 2009 i686 GNU/Linux. I'm willing to provide debug info
to an interested developer, privately.
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists