From: V P <upathiyayan@gmail.com>
To: linux-os@analogic.com
Cc: linux-kernel@vger.kernel.org
Subject: Re: I/O error propagation
Date: Thu, 3 Mar 2005 16:29:39 -0600 [thread overview]
Message-ID: <c9ad8560050303142963fa4bb7@mail.gmail.com> (raw)
In-Reply-To: <Pine.LNX.4.61.0503031506410.7559@chaos.analogic.com>
I agree.
But what if the file systems can handle certain errors better than
what the drivers can do now ? Take for e.g., data corruption. If the
driver finds a corrupted sector that it cannot recover, it is going to
convert this specific error in to a more generic error code (-EIO) and
report it to the file system, But the file system might find it is ok
to have a block of data with few corrupted bytes (say, if the block
belongs to a large video file) rather than receive an I/O error code
with no data at all.
What I'm thinking is this: do we have to export richer error codes to
the filesystem from the driver and let the file system handle them as
it thinks appropriate ?
thanks,
On Thu, 3 Mar 2005 15:20:55 -0500 (EST), linux-os <linux-os@analogic.com> wrote:
> On Thu, 3 Mar 2005, V P wrote:
>
> > Hi,
> >
> > I have a question on how disk errors get propagated to
> > the file systems.
> >
> >> From looking at the SCSI/IDE drivers, it looks like there
> > could be many reasons for an I/O to fail. It could be
> > bus timeout, media errors, and so on.
> >
> > Does all these errors get reported to the file system ?
> > It looks like all the different types of errors get
> > turned into a single I/O error (-EIO) and passed on to the
> > file system.
> >
> > Or is there a way where we can export better error codes
> > to the file system ?
> >
> > Any idea/input regarding this is greatly appreciated.
> >
> > Thanks.
>
> It depends upon the disk devices, i.e., IDE SCSI, etc., but in
> general all errors reported by the hardware result in retrying
> the operation. If the retry fails after several (device dependent)
> attempts, the actual error is reported as a kernel message. These
> errors can be retrieved using the `dmesg` command and they
> will usually be retained in some kernel log in /var/log (actual
> log-name is vendor dependent).
>
> Following the Unix convention, any errors reported back upstream,
> eventually to the user, get reported ONLY as something defined
> in /usr/include/errno.h (which includes others, ultimately
> /usr/asm/errno.h).
>
> So, you don't need to reinvent anything. If you have hardware
> errors they will be reported in /var/log/messages (or whatever)
> and if you are making a new driver, you are expected to comply
> with the same protocol.
>
> Cheers,
> Dick Johnson
> Penguin : Linux version 2.6.10 on an i686 machine (5537.79 BogoMips).
> Notice : All mail here is now cached for review by Dictator Bush.
> 98.36% of all statistics are fiction.
>
prev parent reply other threads:[~2005-03-03 22:36 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-03 19:28 I/O error propagation V P
2005-03-03 20:20 ` linux-os
2005-03-03 22:29 ` V P [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=c9ad8560050303142963fa4bb7@mail.gmail.com \
--to=upathiyayan@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-os@analogic.com \
/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.