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] [thread-next>] [day] [month] [year] [list]

Message-Id: <1AB9AC11-F9E9-4F52-8CBC-D050B056D013@mit.edu>
Date:	Sat, 4 Feb 2012 09:03:43 -0500
From:	Theodore Tso <tytso@....EDU>
To:	htl10@...rs.sourceforge.net
Cc:	Theodore Tso <tytso@....edu>, linux-fsdevel@...r.kernel.org,
	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 Feb 3, 2012, at 9:51 PM, Hin-Tak Leung wrote:

> (I did subscribe to fs-devel, but it seems not to like @sf alias and unsubscribed me after a while - and did that circle a few times; please CC).

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.

> Have a rather broken hard disk at the moment - the bulk of it is ext3 on top of lvm2 - the default for fedora almost exactly 4 years ago. So been doing a lot of 'e2fsck -fv -y ...' lately.
> 
> Am a little surprised about what "Entry <file> in <dir> (<num>) has deleted/unused inode <num>  Clear? yes" does. it deletes the file.
> 
> I wonder should it be re-tried, or relocated to /lost+found, or anything else?

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.

> 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. 

Regards,

-- 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