On Sat, Feb 04, 2012 at 05:53:10PM +0000, Hin-Tak Leung wrote: > > Fair enough - I just thought the interaction between usb-storage and > lvm2 would warrant some wider discussion. If device driver thinks the device has disappeared, and then it reappears so that it gets a new identity (i.e. sdb -> sdc), the problem is below LVM2. It's either a problem with the hardware actually disconnecting from the USB bus, or the with the device driver. But the people who have expertise with the USB device driver and the USB hardware aren't going to be on fs-devel. > 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? If you know that fsck has failed with the automatic (preen) pass, such that you are running fsck interactively by definition you know there will be some decision that will be required. So why not always use the script command when you're running e2fsck interactively? We could replicate the functionality of script in e2fsck, but given that script is a perfectly good implementation, it's not clear it's worth it. > > 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. Well, we don't know that. This is why you really need to get the USB storage folks involved, and they don't hang out on fs-devel. - Ted -- 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
