From: Anton Altaparmakov <aia21@cam.ac.uk>
To: Martin Jambor <jamborm@gmail.com>
Cc: Andrew Morton <akpm@osdl.org>, linux-fsdevel@vger.kernel.org
Subject: Re: What happens to pages that failed to be written to disk?
Date: Sat, 30 Jul 2005 22:13:00 +0100 (BST) [thread overview]
Message-ID: <Pine.LNX.4.60.0507302209350.1408@hermes-1.csi.cam.ac.uk> (raw)
In-Reply-To: <8e70aacf050730124739a9382@mail.gmail.com>
On Sat, 30 Jul 2005, Martin Jambor wrote:
> Hi and thanks for all answers.
>
> On 7/28/05, Andrew Morton <akpm@osdl.org> wrote:
> > > Is the error
> > > somehow signalled to anyone?
> >
> > Yes, it's propagated into the file's address_space for a later
> > fsync()/fdatasync()/msync() to detect.
>
> I see, so a subsequent sync, fsync or umount fail with an error even
> when the writing that failed was not initiated because of them?
>
> > > Do filesystems try to relocate the data
> > > from bad blocks of the device?
> >
> > Nope. Disks will do that internally. If a disk gets a write I/O error
> > it's generally dead.
>
> I am not interested in what happens in HW, I strive to write a filesystem :-)
> Anyway, I see that a write error probably does not happen because of
> bad blocks anyway but because something even worse happened and
> therefore there is no point in it even though our filesystem would be
> able to relocate stuff fairly easily. Am I right?
It can and does happen due to bad blocks. The drive only relocates up to
a certain number (until its spare blocks run out) then defetive blocks
start appearing on disk. We (NTFS developers) have seen a lot of users
with disks with bad blocks on them. And Windows NTFS does relocation so
when a write fails it relocates the data block and repeats the write. So
if your filesystem can do the same then it is definitely worth doing.
The argument that once you start seing bad sectors the disk is going to be
dead soon is wrong as many examples in the field have shown. As Szaka
said it is just like dead pixels on LCD screens. The drive can develop a
certain number and then stop and then work happily for many years.
Best regards,
Anton
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/
prev parent reply other threads:[~2005-07-30 21:13 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-07-28 0:12 What happens to pages that failed to be written to disk? Martin Jambor
2005-07-28 7:33 ` Andrew Morton
2005-07-28 8:38 ` Szakacsits Szabolcs
2005-07-28 16:41 ` Bryan Henderson
2005-07-30 19:47 ` Martin Jambor
2005-07-30 21:13 ` Anton Altaparmakov [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=Pine.LNX.4.60.0507302209350.1408@hermes-1.csi.cam.ac.uk \
--to=aia21@cam.ac.uk \
--cc=akpm@osdl.org \
--cc=jamborm@gmail.com \
--cc=linux-fsdevel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).