--- On Sat, 4/2/12, Theodore Tso <tytso@xxxxxxx> wrote: <snipped> > Most of this message isn't appropriate for > fs-devel. The ext4 bits are > germane to the ext4 list, and the USB read errors should be > taken to > the usb folks. I've removed fs-devel from the > reply-to header, and > I'll ask people who are replying to further edit the cc list > if appropriate. Fair enough - I just thought the interaction between usb-storage and lvm2 would warrant some wider discussion. > This error means the inode entry (and perhaps the entire > inode table > block in your case) has been zapped. So all that's > left is the directory > entry, containing the file name and inode > number. There's nothing > really left to save. > > > I also want to make a suggestion: when such a decision > is made, I'd like to keep a record of what files are lost, > etc. Can an option be added to e2fsck to log its decisions > somewhere? > > I suggest that you look at using the "script" program if you > are running > e2fsck manually, or if you are interested in saving the > output of fsck > during the boot sequence, if your distro isn't already using > logsave, > consider using that binary. That files are lost forever I understand, but from a user's point of view, the most important thing is preserving data, or at least, when lost is inevitable, know that they are lost and hope to recover that somewhere. Is it possible to offer that - i.e. prompt for a log file - when such a decision is needed, when run interactively? > > it appears that some combination of SATA->USB > enclosure plus usb-storage plus usb hci driver doesn't like > read errors, and the kernel resets the usb device and > reconnects whenever that happens. That has the unfortunate > side effect of renaming /dev/sdb into /dev/sdc, etc, > underneath lvm2, and causes lvm2 to get stuck. I suppose > that's the sane behavior since one wants to stop I/O and > further damage, but maybe the kernel should only reset usb > storage devices on write-errors, rather than read-errors? > And somehow limit the device to read-only access after a > read-error? > > I'd suggest that you send your dmesg output to the USB > folks. > That might give them more of an idea which portion of the > stack is causing the stack is causing the > reset. It may very > well be the SATA->USB enclosure is reporting some error > much worse than a read error as a result of the error. Thanks. The curious thing is that running hdparm -a0/-A0 can get around the reset, so it seems to be a performance related issue. -- 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
