http://bugzilla.kernel.org/show_bug.cgi?id=14354 --- Comment #33 from Theodore Tso <tytso@xxxxxxx> 2009-10-13 13:16:01 --- Alexey, the dmesg outputs you are posting --- are these random dmesg's, or ones taken right before the system goes read-only, or the boot session *before* that? If you can easily trigger the file system corruption, something really useful to do would be to set up syslog to do remote logging, so we can get the EXT4 syslog just as or after the root filesystem gets remounted read-only. In addition, it would be useful to get the EXT4 syslog messages for one or two boot sessions *before* the file system was found to be corrupted, as well as the boot session where the file system was found corrupted. If the file system is getting corrupted after the journal is found corrupted due to a checksum mismatch, the syslog file may not have the EXT4 syslog messages, since the file system may end up getting remounted read-only. And in that case, it's useful to see if there are any EXT4 syslog messages or any messages from the device driver showing any I/O errors. The reason why I'm asking about LVM errors and dm-crypt is that at least one fsck log had the name /dev/mapper/sda5_crypt. At this point I'm still trying to find common elements and information leading to a reliable reproduction --- and something that can confirm that this is indeed a regression, so I know whether or not focusing on recent commits is productive. (The theory that it might have something to do with journal checksums is assuming that this is a regression, but so far none of the dmesg is showing the "Journal transaction XXXX is corrupt" that would be expected if the theory that this was caused by a journal checksum failure is correct. So I don't want to focus too soon on recent commits as potential causes of this problem until we know for certain it is a regression.) -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug. -- 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
