Re: sane fsck default behavior for "Entry ... in ... has deleted/unused inode .... Clear? yes"

[Ted Ts'o <tytso@mit.edu>]

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