On Sat, 30 Jul 2005, Martin Jambor wrote:
> Hi and thanks for all answers.
>
> On 7/28/05, Andrew Morton <[EMAIL PROTECTED]> 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/
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
