linux-kernel - Re: ext4: media error but where?

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: <20140706182936.GB471@thunk.org>
Date:	Sun, 6 Jul 2014 14:29:36 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	Pavel Machek <pavel@....cz>
Cc:	kernel list <linux-kernel@...r.kernel.org>,
	adilger.kernel@...ger.ca, linux-ext4@...r.kernel.org
Subject: Re: ext4: media error but where?

On Sun, Jul 06, 2014 at 03:43:25PM +0200, Pavel Machek wrote:
> Hi!
> 
> > Now I'm running fsck.new -cf. I don't think this filesystem has any
> > bad blocks. Still, it says "rootfs: Updating bad block inode."
> > ... "FILE SYSTEM WAS MODIFIED", "REBOOT LINUX".
> 
> And here's patch to fix this uglyness. Unfortunately, it makes it read
> the inode... but perhaps it is good idea as we are able to print
> before/after bad block counts...?
> 
> Signed-off-by: Pavel Machek <pavel@....cz>

Thanks, I'll take a look at these patches.  Honestly, I've been half
tempted to remove the e2fsck -c option entirely.  99.9% of the time,
with modern disks, which has bad block remapping, it doesn't do any
good, and often, it's harmful.

In general, e2fsck -c is not something I recommend people use.  If you
want to use badblocks by itself to see if there are any blocks that
are suffering read problems, that's fine, but if there is, in general
the safest thing to do is to mount the disk read-only, back it up, and
then either (a) reformat and see if you can restore onto it with
backups w/o any further errors, or (b) just trash the disk, and get a
new one, since in general the contents are way more valuable than the
disk itself.  Certainly after trying (a), you get any further errors,
(b) is defintely the way to go.

					- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/