Subject: Re: DEV_B_SIZE
To: None <phk@freebsd.org>
From: Steve Byan <stephen_byan@maxtor.com>
List: tech-kern
Date: 01/31/2003 14:06:11
On Friday, January 31, 2003, at 01:51  PM, phk@freebsd.org wrote:

> In message <A02737C6-354B-11D7-B26B-00306548867E@maxtor.com>, Steve 
> Byan writes
> :
>
>>> The only thing that exposes us to risk is we don't know the risk
>>> exists, so as long as the fact that a 4k physical sector size is
>>> used is not hidden from us, we can adapt.
>>
>> But would existing code be functionally broken (perhaps with respect 
>> to
>> failure recovery) if it were to not be modified to adapt to a 
>> different
>> physical block size?
>
> Not broken any worse than because of write-caching.

Agreed, but IDEMA is proposing to do this to SCSI drives, too.

>
>>> Nope.
>>
>> Really? fsck can recover from losing 4K bytes surrounding the last
>> metadata block written?
>
> If the fragment size is 4k when the filsystem is created, and this
> would happen automatically, then there is no window for lossage.

But if someone were to plug a new 4K-block disk into a system compiled 
to use 512 byte block disks, and the SCSI interface were faked to make 
it appear that the disk could read and write 512-byte blocks, then what 
happens? IDEMA's notion is that faking 512-byte logical size is good 
enough to get new disks to work in systems running legacy code. My fear 
is that it is not so simple.
>
> The thing we really need is working tagged-queing...

Since I believe tagged-queuing works in SCSI, I assume you are asking 
for it in ATA? Or is there some feature missing from SCSI 
tagged-queuing that you'd like to see?

Regards,
-Steve
--------
Steve Byan <stephen_byan@maxtor.com>
Design Engineer
Maxtor Corp.
MS 1-3/E23
333 South Street
Shrewsbury, MA 01545
(508) 770-3414