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, Bill
Attachment:
pgpLf7YIbmK0p.pgp
Description: PGP signature