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. > > 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: comm flush-253:4: 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). So it's the same inode every time. What does # debugfs -R "dump_extents <274258>" /dev/dm-4 show? (or whatever the appropriate device node path is) You might also create an e2image -r fs image so we could take a closer look later if needed. You could provide it offline if filenames are sensitive (no file data is contained in the image). Or you could use the filename obfuscation option. But creating the e2image now just to capture the state might be good. -Eric > 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
