Ted Ts'o, on 08/09/2010 11:32 PM wrote: >>>> It's next to the message on which you originally replied. It was >>>> about ext3, but this time I saw it with ext4. >>> >>> Can you resend, and with a new and specific subject line that is >>> helpful for finding it, and just that one message? >> >> See http://lkml.org/lkml/2010/7/29/222 and >> http://lkml.org/lkml/2010/7/29/325. > > My bet the problem is that iSCSI driver and/or the buffer cache array > doesn't do the right thing with data in the buffer cache which is > didn't actually make it out to the disk (when the I/O finally timed > out), so there is some old data in the buffer cache which doesn't > reflect what is on the disk. > > I suspect that if you run the following command after you umount the > disk, and recover the disk, before you mount the disk again, you run > this command (source attached) on the block device, the journal > recovery should no longer fail. Can you try this experiment? If we > see that this solves the problem, then we can force a buffer cache > flush at mount-time, so that it happens automatically. I ran the program just before the mount and it changed nothing: [36630.781663] e1000: eth2 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX # ./a.out /dev/sdb # mount -t ext4 /dev/sdb /mnt [36640.487208] JBD: recovery failed [36640.500639] EXT4-fs (sdb): error loading journal # mount -t ext4 /dev/sdb /mnt [36721.642852] EXT4-fs (sdb): ext4_orphan_cleanup: deleting unreferenced inode 128135 [36721.669780] EXT4-fs (sdb): ext4_orphan_cleanup: deleting unreferenced inode 128136 [36721.696432] EXT4-fs (sdb): 2 orphan inodes deleted [36721.709978] EXT4-fs (sdb): recovery complete [36721.730531] EXT4-fs (sdb): mounted filesystem with ordered data mode Vlad -- 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
