On Wed, Mar 06, 2002 at 11:43:16AM -0500, Zhihui Zhang wrote: > > > On Tue, 5 Mar 2002, Brian T.Schellenberger wrote: > > > On Tuesday 05 March 2002 06:32 pm, Zhihui Zhang wrote: > > > I apologize for all who have followed this. I made a typo in the original > > > email. What I observed is that writing LESS performs WORSE. Since all > > > blocks are laid out contiguously and I write them sequentially, there > > > should not be any seek problem. > > > > Hmmm . . . perhaps I misunderstood you, but I thought that you said that in > > the original mail that you were writing to the same number of disk blocks > > eiteher way but in some cases you were writing partial blocks and in some > > cases full blocks. How do you do that if you don't seek? > > > > If you aren't seeking, then you must be, in the slower case, writing partial > > blocks. Well, there is some size where the disk has physical blocks. On > > some disks, writes are always done in full physical blocks. To write a > > partial block, the block is read from disk, the data to be written is > > substituted and then the entire block is written. This would certainly be > > likely to be slower than writing a whole block. > > In the case of partial block writes, I move to the next block which is > contiguous to the current block. So the start address of each write in > both cases are exactly the same. The only difference is that one write > full blocks, the other write partial blocks. I also do not read anything > during the partial block write, and I think the disk controller should not > do that either.
If 'moving to the next block' means a seek, that is, if write_block() seeks forward, then maybe this part of an earlier message in the thread by Brian T.Schellenberger would be helpful: : If, however, the later mail is right and the earlier mail is wrong, this : *would* be easily explained: Many disks have optimization for the case of : linear writes and seeking slows them down a *lot*. Why? Because it's very : common to do linear writes, and it make sense to optimize the common case. Besides the linear optimization case, which would definitely slow down the seeking (second method), please do try to factor caching out of the equation, as several people suggested several times, by transferring much more data, like a couple of GB or at least twice as much as your physical memory, and post the results of that. G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED] [EMAIL PROTECTED] PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 Thit sentence is not self-referential because "thit" is not a word.
msg32500/pgp00000.pgp
Description: PGP signature
