Date: Wed, 6 Mar 2002 19:10:55 +0200 From: Peter Pentchev <roam@ringlet.net> To: Zhihui Zhang <zzhang@cs.binghamton.edu> Cc: "Brian T.Schellenberger" <bts@babbleon.org>, Lars Eggert <larse@ISI.EDU>, "Rogier R. Mulhuijzen" <drwilco@drwilco.net>, Julian Elischer <julian@elischer.org>, freebsd-hackers@FreeBSD.ORG Subject: Re: A weird disk behaviour Message-ID: <20020306191055.F14052@straylight.oblivion.bg> In-Reply-To: <Pine.SOL.4.21.0203061132090.5743-100000@onyx>; from zzhang@cs.binghamton.edu on Wed, Mar 06, 2002 at 11:43:16AM -0500 References: <20020306025055.2C1B5BA03@i8k.babbleon.org> <Pine.SOL.4.21.0203061132090.5743-100000@onyx>
next in thread | previous in thread | raw e-mail | index | archive | help
--3oCie2+XPXTnK5a5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 06, 2002 at 11:43:16AM -0500, Zhihui Zhang wrote: >=20 >=20 > On Tue, 5 Mar 2002, Brian T.Schellenberger wrote: >=20 > > 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 orig= inal > > > 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. > >=20 > > Hmmm . . . perhaps I misunderstood you, but I thought that you said tha= t in=20 > > the original mail that you were writing to the same number of disk bloc= ks=20 > > eiteher way but in some cases you were writing partial blocks and in so= me=20 > > cases full blocks. How do you do that if you don't seek? > >=20 > > If you aren't seeking, then you must be, in the slower case, writing pa= rtial=20 > > blocks. Well, there is some size where the disk has physical blocks. = On=20 > > some disks, writes are always done in full physical blocks. To write a= =20 > > partial block, the block is read from disk, the data to be written is= =20 > > substituted and then the entire block is written. This would certainly= be=20 > > likely to be slower than writing a whole block. >=20 > 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 ve= ry : 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 --=20 Peter Pentchev roam@ringlet.net roam@FreeBSD.org 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. --3oCie2+XPXTnK5a5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjyGTZ8ACgkQ7Ri2jRYZRVNKLwCfeSnMd8Ma/a3lFFCbVRgypT00 qQ0An2c7bjqz7dTKZ/gtWDTAb9NZl0fK =rcpX -----END PGP SIGNATURE----- --3oCie2+XPXTnK5a5-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020306191055.F14052>