public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@suse.de>
To: Andre Hedrick <andre@linux-ide.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
	Daniel Stodden <stodden@in.tum.de>,
	linux-kernel@vger.kernel.org
Subject: Re: hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error }
Date: Thu, 27 Dec 2001 15:54:03 +0100	[thread overview]
Message-ID: <20011227155403.A1730@suse.de> (raw)
In-Reply-To: <E16I8j1-0000ah-00@the-village.bc.nu> <Pine.LNX.4.10.10112231200500.12646-100000@master.linux-ide.org>
In-Reply-To: <Pine.LNX.4.10.10112231200500.12646-100000@master.linux-ide.org>

On Sun, Dec 23 2001, Andre Hedrick wrote:
> the content is primarily the FS.  Should an APP close a file but it is
> still in buffer_cache, there is no way to notify the app or the user or
> anything associated with the creation/closing of that file, if a write
> error occurs.
> 
> So we have user-space believing it is success.

We have a buggy user-space app believing it is a success -- do you
really believe programs like eg mta's ignorantly closes a file and just
hopes for the best? fsync.

> FS doing an initial ACK of success.
> BLOCK generating the request to the low_level.
> LOW_LEVEL goes OH CRAP, I am having a problem and can not complete.
> 
> LOW_LEVEL goes, HEY BLOCK we have a problem.
> BLOCK, that is nice whatever ....

What does this _mean_?

> This is a bad model, an worse is
> 
> LOW_LEVEL goes, HEY BLOCK we have a problem.
> BLOCK goes, HEY FS we have an annoying LOW_LEVEL asking for reissue.
> FS, duh which way did the rabbit go ...

retries belong at the low level, once you pass up info of failure to the
upper layers it's fatal. time for FS to shut down.

> > Incidentally the EVMS IBM volume manager code does support bad block
> > remapping in some situations.
> 
> Well managing badblock can be a major pain, but it is the right thing to
> do.  Now what is the cost, since there is surge in journaling FS's that
> have logs.  The cost is coming up w/ a sane way to manage the mess.
> Even before we get to managing the mess, we have to be able to reissue the
> request to a reallocated location, and make all kinds of noise that we are
> doing heroic attempts to save the data.  These may include --

Irk, software managed bad block remapping is horrible.

> The issue is we are doing nothing to address the point, and it is arrogant
> for the maintainers of the various storage classes and the supported upper
> layers not willing to address this issue.

How about showing solutions in form of patches instead bitching about
this again and again? Frankly, I'm pretty sick of just seeing pointless
talk about the issue.

-- 
Jens Axboe


  reply	other threads:[~2001-12-27 14:54 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-12-06  6:13 hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error } Daniel Stodden
2001-12-06  6:55 ` Sven.Riedel
2001-12-06 15:04 ` Matthias Andree
2001-12-23  7:24 ` Andre Hedrick
2001-12-23  7:53   ` Andrew Morton
2001-12-22 20:25     ` T. A.
2001-12-23 11:18     ` Peter Osterlund
2001-12-23 13:31   ` Alan Cox
2001-12-23 22:08     ` Andre Hedrick
2001-12-27 14:54       ` Jens Axboe [this message]
2001-12-27 16:42         ` Alan Cox
2001-12-27 16:51           ` Jens Axboe
2001-12-27 17:46             ` Linus Torvalds
2001-12-27 18:32               ` Andre Hedrick
2001-12-27 21:15               ` Legacy Fishtank
2001-12-27 17:50             ` Alan Cox
2001-12-28  2:05         ` Andre Hedrick
2001-12-28 10:59           ` Jens Axboe
2001-12-28 12:29             ` Rik van Riel
2001-12-28 12:33               ` Jens Axboe
2001-12-28 13:00                 ` Jens Axboe
2001-12-28 19:30                 ` Peter Osterlund
2001-12-29 15:07                   ` Jens Axboe
2001-12-28 20:23             ` Andre Hedrick
2001-12-29 14:15               ` Jens Axboe
2001-12-29 20:58                 ` You WIN Andre Hedrick
2001-12-31 12:58                   ` Jens Axboe

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=20011227155403.A1730@suse.de \
    --to=axboe@suse.de \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=andre@linux-ide.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stodden@in.tum.de \
    /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