Re: blocksizes

[Michael van Elst <mlelstv%serpens.de@localhost>]

On Sun, Jan 24, 2010 at 11:16:05PM +1030, Brett Lymn wrote:
> On Fri, Jan 22, 2010 at 01:09:10PM +0100, Michael van Elst wrote:
> > 
> > Keeping DEV_SIZE at 512 bytes avoids lots of changes.
> > 
> 
> Won't that mean there is a chance there will be a lot of
> read/modify/write going on if the driver is pretending to have 512byte
> sectors?

No, the driver will not support writes of single 512byte sectors
if the underlying hardware does not provide 512byte sectors.

We are only talking about the API and what units are used to
specify disk addresses and block counts. So on a disk with
1K sectors you will address blocks 0,2,4,6,... and you can
only transfer an even number of blocks.


> Would that not be really really bad for NFS write performance
> since the NFS spec says a write has to hit the media before being
> confirmed then wouldn't a streaming write of 512byte sectors would
> cause a lot of sequential read/modify/write as each 512byte chunk of
> the underlying disk block size was updated?

Assuming we had read-modify-write cycles this would be true. But
writing NFS with 512byte buffers is slow anyway and NFSv3 is a bit
smarter when buffering. N.B. the same also happens with any write
smaller than the filesystem block or fragment size (which is not
directly related to physical sectors).


N.B. So far I have MSDOSFS and FFS running on a disk with 1K sectors
and I learned that the block size translation is already done
in our block drivers, so there is no need to funnel I/O through dk.


Greetings,
-- 
                                Michael van Elst
Internet: mlelstv%serpens.de@localhost
                                "A potential Snark may lurk in every tree."