tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: blocksizes

On Sun, Jan 24, 2010 at 02:37:24PM +0100, Michael van Elst wrote:
> 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.

Teach me to not read the whole thread before responding!

I think you're re-learning some of the reasons that Chuq went w/ leaving 
things in DEV_BSIZE units.

Take care,


Attachment: pgpLf7YIbmK0p.pgp
Description: PGP signature

Home | Main Index | Thread Index | Old Index