linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andre Hedrick <andre@linux-ide.org>
To: jw schultz <jw@pegasys.ws>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Blockbusting news, results end
Date: Mon, 27 Oct 2003 14:27:09 -0800 (PST)	[thread overview]
Message-ID: <Pine.LNX.4.10.10310271425000.14405-100000@master.linux-ide.org> (raw)
In-Reply-To: <20031027205854.GF8540@pegasys.ws>


To date IDEMA has not released a formal spec for drive makers to switch to
4Kb sectors.  If they have, then when running in compatibility mode, a
heavy read-modify-write happens to goto the pseudo sector of 512b.

Linux can not handled new IDEMA calls currently.

Cheers,

Andre Hedrick
LAD Storage Consulting Group

On Mon, 27 Oct 2003, jw schultz wrote:

> On Sun, Oct 26, 2003 at 08:25:26PM +0900, Norman Diamond wrote:
> > Pavel Machek replied to me:
> > 
> > > > The drive finally reallocated the block and there are no longer any
> > > > visible bad blocks.
> > >
> > > And what was the operation that made it realocate?
> > 
> > At first I wasn't sure.  I noticed that the drive was behaving differently
> > when I told dd to use bs=4096 instead of 512.  Until seeing Oleg Drokin's
> > message about ReiserFS, I thought that the drive itself was doing something
> > differently.  That didn't make much sense to me because the physical sectors
> > are much longer than 4096 and the pseudo-sectors are the conventional 512,
> > so why did 4096 cause different behaviour?  From Oleg Drokin's message, I
> > guess that the use of 4096 might make a difference in the sequence of
> > read-modify-write cycles involved in the logical write operation.
> 
> You bring up an interesting point.  If the physical sector
> is larger than the data being written how can the drive
> reallocate the sector without silently losing data?
> 
> To put it in the concrete, if the physical sector were 16K
> and we only do a 4K write and there is a unrecoverable read
> error on the physical sector as part of the
> read-modify-write sequence what is the drive to do?  The
> other 12K for which the drive has no data could be other
> files not related to the 4K being written or even filesystem
> meta-data.  Reallocation in that case would cause silent
> corruption.
> 
> Perhaps what finally allowed the reallocation was that the
> entire physical sector finally accumulated writes to all the
> logical sectors needed to be a complete physical sector
> write.
> 
> -- 
> ________________________________________________________________
> 	J.W. Schultz            Pegasystems Technologies
> 	email address:		jw@pegasys.ws
> 
> 		Remember Cernan and Schmitt
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 


  reply	other threads:[~2003-10-27 22:28 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-10-26  8:49 Blockbusting news, results end Norman Diamond
2003-10-26  9:22 ` Pavel Machek
2003-10-26 11:25   ` Norman Diamond
2003-10-27 20:58     ` jw schultz
2003-10-27 22:27       ` Andre Hedrick [this message]
2003-10-27 22:57         ` jw schultz
2003-10-28  2:03           ` jw schultz
2003-10-26 11:01 ` Hans Reiser
2003-10-26 12:59   ` Oleg Drokin
2003-10-26 12:05     ` Hans Reiser
2003-10-26 12:39       ` Oleg Drokin
2003-10-26 16:26         ` Hans Reiser
2003-10-26 17:13           ` Oleg Drokin
2003-10-26 18:20             ` Hans Reiser
2003-10-26 19:07               ` Oleg Drokin
2003-10-27 12:44                 ` Vitaly Fertman
2003-10-26 18:39 Mudama, Eric
2003-10-27  9:45 ` Norman Diamond
2003-10-27 10:48   ` Krzysztof Halasa
2003-10-27 17:50 Mudama, Eric
2003-10-28 11:31 Norman Diamond
2003-10-28 16:10 Mudama, Eric
2003-10-28 18:30 ` 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=Pine.LNX.4.10.10310271425000.14405-100000@master.linux-ide.org \
    --to=andre@linux-ide.org \
    --cc=jw@pegasys.ws \
    --cc=linux-kernel@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).