linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Szakacsits Szabolcs <szaka@sienet.hu>
To: Andrew Morton <akpm@osdl.org>
Cc: Martin Jambor <jamborm@gmail.com>, linux-fsdevel@vger.kernel.org
Subject: Re: What happens to pages that failed to be written to disk?
Date: Thu, 28 Jul 2005 10:38:20 +0200 (MEST)	[thread overview]
Message-ID: <Pine.LNX.4.21.0507280948530.1201-100000@mlf.linux.rulez.org> (raw)
In-Reply-To: <20050728003326.4add1a0f.akpm@osdl.org>


On Thu, 28 Jul 2005, Andrew Morton wrote:
> Martin Jambor <jamborm@gmail.com> wrote:
> >
> > Do filesystems try to relocate the data from bad blocks of the
> > device?

Only Windows NTFS, not others AFAIK (most filesytems can mark them during
mkfs, that's all).

> Nope.  Disks will do that internally.  If a disk gets a write I/O error
> it's generally dead.

That's what I thought also for over a decade (that they are basically dead
soon) so originally I disabled NTFS resizing support for such disks (the
tool is quite widely used since it's the only free, open source NTFS
resizer).

However over the last three years users convinced me that it's quite ok
having a few bad sectors (not only in the remapping area). I investigated
several "dead" disks and the pattern was that they had maximum a dozen bad
sectors, the disk quality didn't degrade in time and users sweared they
never had any problem (crash, data loss, corruption, whatever).

So recently I added optional support for working with such "dead" disks
and this is a bit frustrating since if users don't run badblocks in 
such cases when creating the Linux filesystems then they will have a
hopefully not too spectacular encounter with these sectors sooner or
later.

Of course I don't say that all disks having bad sectors are totally ok and
never will die. Only that that it seems some subset of them seems to keep
working perfectly fine (the issue looks similar to the "having a few dead
pixel" problem on some LCD's and laptops).

	Szaka


  reply	other threads:[~2005-07-28  8:38 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 [this message]
2005-07-28 16:41     ` Bryan Henderson
2005-07-30 19:47   ` Martin Jambor
2005-07-30 21:13     ` Anton Altaparmakov

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.21.0507280948530.1201-100000@mlf.linux.rulez.org \
    --to=szaka@sienet.hu \
    --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).