On 11/2/12 10:50 AM, Tim Landscheidt wrote: > (anonymous) wrote: > >> FYI, after fsck'ing, I checked my filesystem against my backup, and didn't >> find anything that changed that shouldn't have changed. Command I used >> was: > >> rsync -imva --compare-dest=/ /media/4tb/bak/dancer-2012-09-04/ /media/4tb/bak/changes/ > > I ran (or rather run) into this issue as well. Starting on > October 22nd, I saw on my Fedora 16 (3.6.2-1.fc16.i686) sys- > tem: > > | Oct 22 13:56:44 passepartout kernel: [ 1395.772939] EXT4-fs error (device dm-4): ext4_ext_search_left:1238: inode #274258: comm flush-253:4: ix (3666) != EXT_FIRST_INDEX (0) (depth 0)! > | Oct 22 13:56:44 passepartout kernel: [ 1395.772951] EXT4-fs (dm-4): delayed block allocation failed for inode 274258 at logical offset 3666 with max blocks 3 with error -5 > | Oct 22 13:56:44 passepartout kernel: [ 1395.772955] EXT4-fs (dm-4): This should not happen!! Data will be lost > | Oct 22 13:56:44 passepartout kernel: [ 1395.772957] > > and it continued intermittently. Last message before "yes- > terday"'s shutdown was: > > | Nov 2 04:14:09 passepartout kernel: [51109.016422] EXT4-fs error (device dm-4): ext4_ext_search_left:1304: inode #274258: comm flush-253:4: ix (3666) != EXT > | _FIRST_INDEX (0) (depth 0)! > | Nov 2 04:14:09 passepartout kernel: [51109.016428] EXT4-fs (dm-4): delayed block allocation failed for inode 274258 at logical offset 3792 with max blocks 2 > | with error -5 > | Nov 2 04:14:09 passepartout kernel: [51109.016431] EXT4-fs (dm-4): This should not happen!! Data will be lost > | Nov 2 04:14:09 passepartout kernel: [51109.016431] > > Looking at today's boot.log, I see no error detected by > "File System Check", and the manual run of "e2fsck -f" > showed also no errors. Hm, on the image you provided to me for analysis, it was indeed somewhat corrupted; I got about 400 lines of output from e2fsck. However - did you take the image while it was mounted, or did you unmount it first? Anyway, inode 274258 wasn't in the fsck output. However, I can reproduce the error you got: [429903.549764] EXT4-fs error (device loop0): ext4_ext_search_left:1252: inode #274258: comm flush-7:0: ix (3666) != EXT_FIRST_INDEX (0) (depth 0)! so I'll see what's going on here. Thanks, -Eric > Shortly after starting Chrome, the messages reappeared > again: > > | Nov 2 15:15:48 passepartout kernel: [ 1979.196296] EXT4-fs error (device dm-4): ext4_ext_search_left:1304: inode #274258: ix (3666) != EXT_FIRST_INDEX (0) (depth 0)! > | Nov 2 15:15:48 passepartout kernel: [ 1979.196306] EXT4-fs (dm-4): delayed block allocation failed for inode 274258 at logical offset 3672 with max blocks 2 with error -5 > | Nov 2 15:15:48 passepartout kernel: [ 1979.196308] EXT4-fs (dm-4): This should not happen!! Data will be lost > | Nov 2 15:15:48 passepartout kernel: [ 1979.196308] > > And indeed: > > | [root@passepartout ~]# find ~tim -inum 274258 > | /home/tim/.cache/google-chrome/Default/Cache/data_3 > | [root@passepartout ~]# > > So somehow Chromium/Chrome seems to be able to trigger ker- > nel messages indicating a file system error while no actual > file system errors seem to occur (very big assumption here > because I have no idea how to detect if "data_3" is cor- > rupted). > > In my yum.log, I don't see any obvious package update prior > to October 22nd. kernel was updated on October 23rd, Chrome > on October 12th (22.0.1229.94-161065.i386). > > Any ideas? > > TIA, > Tim > > -- > 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 > -- 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
