Subject: Re: DEV_B_SIZE
To: None <firstname.lastname@example.org>
From: Steve Byan <email@example.com>
Date: 01/31/2003 14:06:11
On Friday, January 31, 2003, at 01:51 PM, firstname.lastname@example.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
>> failure recovery) if it were to not be modified to adapt to a
>> physical block size?
> Not broken any worse than because of write-caching.
Agreed, but IDEMA is proposing to do this to SCSI drives, too.
>> 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?
Steve Byan <email@example.com>
333 South Street
Shrewsbury, MA 01545