All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hans Reiser <reiser@namesys.com>
To: Norman Diamond <ndiamond@wta.att.ne.jp>
Cc: Wes Janzen <superchkn@sbcglobal.net>,
	Rogier Wolff <R.E.Wolff@BitWizard.nl>,
	John Bradford <john@grabjohn.com>,
	linux-kernel@vger.kernel.org, nikita@namesys.com,
	Pavel Machek <pavel@ucw.cz>, Vitaly Fertman <vitaly@namesys.com>
Subject: Re: Blockbusting news, this is important (Re: Why are bad disk sectors numbered strangely, and what happens to them?)
Date: Fri, 17 Oct 2003 15:45:10 +0400	[thread overview]
Message-ID: <3F8FD646.9070902@namesys.com> (raw)
In-Reply-To: <126d01c3949f$91bdecc0$3eee4ca5@DIAMONDLX60>

Norman Diamond wrote:

>Replying first to Hans Reiser; below to Russell King and Pavel Machek.
>
>  
>
>>Instead of recording the bad blocks, just write to them.
>>    
>>
>
>If writes are guaranteed to force reallocations then this is potentially
>part of a solution.
>
>I still remain suspicious because the first failed read was milliseconds or
>minutes after the preceding write.  I think the odds are very high that the
>sector was already bad at the time of the write but reallocation did not
>occur.  It is possible but I think very unlikely that the sector was
>reallocated to a different physical sector which went bad milliseconds after
>being written after reallocation, and equally unlikely that the sector
>wasn't reallocated because it really hadn't been bad but went bad
>milliseconds later.  In other words, I think it is overwhelmingly likely
>that the write failed but was not detected as such and did not result in
>reallocation.
>  
>
perform the write after the failed read, that way the drive knows it is 
a bad block at the time you write.

>Now, maybe there is a technique to force it anyway.  When a partition is
>newly created and is being formatted with the intention of writing data a
>few minutes later, do writes that "should" have a better chance of being
>detected.  The way to start this is to simply write every block, but this is
>obviously insufficient because my block did get written shortly after the
>partition was formatted and that write didn't cause the block to be
>reallocated.  So in addition to simply writing every block, also read every
>block.  For each read that fails, proceed to do another write which "should"
>force reallocation.
>
>Mr. Reiser, when I created a partition of your design, that technique was
>not offered.  Why?  And will it soon start being offered?
>  
>
I think I discussed with Vitaly offering users the option of writing, 
reading, and then writing again, every block before mkreiserfs.  I 
forget what happened to that idea, Vitaly?

>Also, I remain highly suspicious that for each read that fails, when the
>formatting program proceeds to do another write which "should" force
>reallocation, the drive might not do it.
>
I am not going to worry about such suspicions without evidence or drive 
manufacturer comment, as it has not been our experience so far.

>
>
>Why does it matter?  The drive already reported a read failure.  Maybe Linux
>programs aren't all smart enough to inform the user when a read operation
>results in an I/O error, but drivers could be smarter.
>
There is a general problem with reporting urgent kernel messages to 
users thanks to GUIs covering over the console.



-- 
Hans



  reply	other threads:[~2003-10-17 11:45 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-10-13  9:31 Why are bad disk sectors numbered strangely, and what happens to them? Norman Diamond
     [not found] ` <200310131014.h9DAEwY3000241@81-2-122-30.bradfords.org.uk>
2003-10-13 10:24   ` Norman Diamond
2003-10-13 10:33     ` John Bradford
2003-10-13 11:30       ` Norman Diamond
2003-10-13 11:58         ` Maciej Zenczykowski
2003-10-15 10:22           ` Norman Diamond
2003-10-13 12:02         ` John Bradford
2003-10-15 10:23           ` Norman Diamond
2003-10-15 18:56             ` Pavel Machek
2003-10-14  6:54         ` Rogier Wolff
2003-10-13 14:24     ` Chuck Campbell
2003-10-13 14:54       ` Maciej Zenczykowski
2003-10-13 16:29         ` Roger Larsson
2003-10-14  6:49     ` Rogier Wolff
2003-10-14  7:05       ` Wes Janzen
2003-10-14  7:21         ` John Bradford
2003-10-14  7:40           ` Rogier Wolff
2003-10-14  8:11             ` John Bradford
2003-10-14  8:45               ` Hans Reiser
2003-10-14  9:46                 ` Rogier Wolff
2003-10-14  9:57                   ` Hans Reiser
2003-10-14 10:10                     ` Rogier Wolff
2003-10-14 10:31                       ` Hans Reiser
2003-10-14 10:19                 ` John Bradford
     [not found]             ` <200310140800.h9E80BT9000815@81-2-122-30.bradfords.org.uk>
     [not found]               ` <20031014081110.GA14418@bitwizard.nl>
2003-10-14  8:55                 ` Wes Janzen
2003-10-14 10:05                   ` Rogier Wolff
2003-10-14  7:24         ` Rogier Wolff
2003-10-14  9:04         ` Hans Reiser
2003-10-15 10:23           ` Norman Diamond
2003-10-15 10:39             ` Hans Reiser
2003-10-17  9:40           ` Blockbusting news, this is important (Re: Why are bad disk sectors numbered strangely, and what happens to them?) Norman Diamond
2003-10-17  9:48             ` Hans Reiser
2003-10-17 11:11               ` Norman Diamond
2003-10-17 11:45                 ` Hans Reiser [this message]
2003-10-17 11:51                 ` John Bradford
2003-10-17 12:53                 ` John Bradford
2003-10-17 13:03                   ` Russell King
2003-10-17 13:26                     ` John Bradford
2003-10-19  7:50                   ` Andre Hedrick
2003-10-17 13:04                 ` Russell King
2003-10-17 14:09                   ` Norman Diamond
2003-10-17  9:58             ` Pavel Machek
2003-10-17 10:15               ` Hans Reiser
2003-10-17 10:24             ` Rogier Wolff
2003-10-17 10:49               ` John Bradford
2003-10-17 11:09                 ` Rogier Wolff
2003-10-17 11:24                 ` Krzysztof Halasa
2003-10-17 19:35                   ` John Bradford
2003-10-17 23:28                     ` Krzysztof Halasa
2003-10-18  7:42                       ` Pavel Machek
2003-10-18  8:30                         ` John Bradford
2003-10-21 20:26                           ` bill davidsen
2003-10-18  8:27                       ` John Bradford
2003-10-18 12:02                         ` Krzysztof Halasa
2003-10-18 16:26                           ` Nuno Silva
2003-10-18 20:16                             ` Krzysztof Halasa
     [not found]                     ` <m37k33igui.fsf@defiant. <m3u166vjn0.fsf@defiant.pm.waw.pl>
2003-10-21 20:39                       ` bill davidsen
2003-10-17 10:37             ` ATA Defect management John Bradford
2003-10-21 20:44               ` bill davidsen
2003-10-17 12:08             ` Blockbusting news, this is important (Re: Why are bad disk sectors numbered strangely, and what happens to them?) Justin Cormack
2003-10-21 20:12             ` bill davidsen

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=3F8FD646.9070902@namesys.com \
    --to=reiser@namesys.com \
    --cc=R.E.Wolff@BitWizard.nl \
    --cc=john@grabjohn.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ndiamond@wta.att.ne.jp \
    --cc=nikita@namesys.com \
    --cc=pavel@ucw.cz \
    --cc=superchkn@sbcglobal.net \
    --cc=vitaly@namesys.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.