linux-ext4 - 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 for Android: free password hash cracker in your pocket

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

Message-ID: <1328323907.72548.YahooMailClassic@web29505.mail.ird.yahoo.com>
Date:	Sat, 4 Feb 2012 02:51:47 +0000 (GMT)
From:	Hin-Tak Leung <htl10@...rs.sourceforge.net>
To:	linux-fsdevel@...r.kernel.org, tytso@...rs.sourceforge.net,
	linux-ext4@...r.kernel.org
Subject: sane fsck default behavior for "Entry ... in ... has deleted/unused inode ....  Clear? yes"

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

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?

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?

Thanks for all the hard-work to make fsck even possible - the hard disk has been well-used :-).

For those people who might come across this in the future - here is a tips, and may be another question/discussion about sane behavior on error:

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?

In any case, I somehow found that I could persuade the kernel not to reset the usb device, if I disable read-ahead (i.e. hdparm -a0/-A0). I also tried disabling read-ahead on the lvm2 device itself (-A0 /dev/dm-X, where X is the logical volume), and "echo 128 > /sys/block/sdc/device/max_sectors" (or smaller number).

So it seems that slowing it down make it more reliable for an unreliable disk. Maybe this can be made automatic inside the kernel?

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