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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20120206000353.GA13391@thunk.org>
Date:	Sun, 5 Feb 2012 19:03:53 -0500
From:	Ted Ts'o <tytso@....edu>
To:	Hin-Tak Leung <htl10@...rs.sourceforge.net>
Cc:	tytso@...rs.sourceforge.net,
	Ext4 Developers List <linux-ext4@...r.kernel.org>
Subject: Re: sane fsck default behavior for "Entry ... in ... has
 deleted/unused inode ....  Clear? yes"

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html