public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andreas Dilger <adilger@clusterfs.com>
To: "Jörn Engel" <joern@wohnheim.fh-wedel.de>
Cc: Junfeng Yang <yjf@stanford.edu>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	ext2-devel@lists.sourceforge.net, mcs@stanford.edu,
	Madanlal S Musuvathi <madan@stanford.edu>,
	"David L. Dill" <dill@cs.stanford.edu>
Subject: Re: [Ext2-devel] [CHECKER] warnings in fs/ext3/namei.c (2.4.19) where disk read errors get ignored, causing non-empty dir to be deleted
Date: Mon, 3 May 2004 11:54:25 -0600	[thread overview]
Message-ID: <20040503175425.GL1334@schnapps.adilger.int> (raw)
In-Reply-To: <20040503173320.GA10655@wohnheim.fh-wedel.de>

On May 03, 2004  19:33 +0200, Jörn Engel wrote:
> On Mon, 3 May 2004 10:16:06 -0600, Andreas Dilger wrote:
> > If that's what you want, then mount the filesystem with "errors=remount-ro"
> > and you will get it.  You can even mount it with "errors=panic" so that the
> > node reboots and does a full fsck immediately.  For users that have a few
> > bad blocks on their disk and can't afford to throw the whole disk away this
> > is a reasonable course of action.
> 
> Ok, "errors=remount-ro" is good enough for me.  For the record, do
> non-historic disks with a few bad blocks still exist?  I though the
> driver firmware already detected those and used spare blocks at one
> side of the disk as a replacement.  Nicely visible when sequential
> read performance over the whole disk has a few non-continuous spots.

AFAIK, even modern disks will only remap blocks at write time and not
at read time.  That is why it is possible to get an IO error, but when
someone runs e.g. "badblocks" on the disk they are confused when it
doesn't report any errors.

Things like allowing the directory to be removed when there is a read
error actually helps such situations because when the block is re-used
it will first be written to and that will cause the remapping to happen.
Otherwise you have this useless directory that you don't want and can't
remove.  It doesn't help anyone to refuse removing it.

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/


      reply	other threads:[~2004-05-03 17:54 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-04-27  6:41 [CHECKER] warnings in fs/ext3/namei.c (2.4.19) where disk read errors get ignored, causing non-empty dir to be deleted Junfeng Yang
2004-04-27  7:44 ` [Ext2-devel] " Andreas Dilger
2004-05-03  9:59   ` Pavel Machek
2004-05-03 14:10   ` Jörn Engel
2004-05-03 16:16     ` Andreas Dilger
2004-05-03 17:33       ` Jörn Engel
2004-05-03 17:54         ` Andreas Dilger [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040503175425.GL1334@schnapps.adilger.int \
    --to=adilger@clusterfs.com \
    --cc=dill@cs.stanford.edu \
    --cc=ext2-devel@lists.sourceforge.net \
    --cc=joern@wohnheim.fh-wedel.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=madan@stanford.edu \
    --cc=mcs@stanford.edu \
    --cc=yjf@stanford.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox