All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@suse.de>
To: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>,
	Helge Hafting <helgehaf@aitel.hist.no>,
	linux-kernel@vger.kernel.org
Subject: Re: [Q] FAT driver enhancement
Date: Wed, 3 Apr 2002 09:07:03 +0200	[thread overview]
Message-ID: <20020403070703.GF1465@suse.de> (raw)
In-Reply-To: <20020328135555.U6796-100000@snail.stack.nl> <871ye479sz.fsf@devron.myhome.or.jp> <3CA97B1A.13E6765D@aitel.hist.no> <87663acjs7.fsf@devron.myhome.or.jp> <20020402221325.GC961@matchmail.com>

On Tue, Apr 02 2002, Mike Fedyk wrote:
> On Tue, Apr 02, 2002 at 10:27:52PM +0900, OGAWA Hirofumi wrote:
> > Helge Hafting <helgehaf@aitel.hist.no> writes:
> > 
> > > OGAWA Hirofumi wrote:
> > > > 
> > > > Jos Hulzink <josh@stack.nl> writes:
> > > > > Questions:
> > > > >
> > > > > 1) How do you think about the checking of the FAT tables ? It definitely
> > > > >    will slow down the mount.
> > > > 
> > > > Unfortunately if FAT table has bad sector, FAT tables may not be the
> > > > same.
> > > 
> > > And then you don't want to mount unless you know what you
> > > are doing.  And those knowing what they are doing can be bothered
> > > to use some kind of "force" option in this case.  Or perhaps an
> > > option that selects which FAT to trust.
> > 
> > I mean I/O error, not data damage.
> 
> It is the block layer's responsibility to retry such soft errors and recover.

No it's the low level driver

> Probably the best you can do, is retry the read a few times if there
> is an error reported, and then fail if it persists.

I/O error retrying from the fs is a bad idea, the low level driver
should already have exhausted the possibilities to recover the data. If
the fs receives an I/O error, that's the final result and retrying
would serve no sane purpose.

-- 
Jens Axboe


  reply	other threads:[~2002-04-03  7:07 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-03-28 13:25 [Q] FAT driver enhancement Jos Hulzink
2002-03-28 19:48 ` OGAWA Hirofumi
2002-04-02  9:34   ` Helge Hafting
2002-04-02 13:27     ` OGAWA Hirofumi
2002-04-02 22:13       ` Mike Fedyk
2002-04-03  7:07         ` Jens Axboe [this message]
2002-04-03 11:54         ` OGAWA Hirofumi
2002-04-03 12:21           ` Jos Hulzink
2002-04-03 12:45             ` OGAWA Hirofumi
2002-04-03 12:48             ` David D. Hagood
2002-04-04  0:06               ` Thunder from the hill
2002-03-29 23:11 ` Pavel Machek

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=20020403070703.GF1465@suse.de \
    --to=axboe@suse.de \
    --cc=helgehaf@aitel.hist.no \
    --cc=hirofumi@mail.parknet.co.jp \
    --cc=linux-kernel@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.