Date: Wed, 6 Mar 2002 10:54:32 -0800 (PST) From: Julian Elischer <julian@elischer.org> To: Zhihui Zhang <zzhang@cs.binghamton.edu> Cc: Peter Edwards <peter.edwards@openet-telecom.com>, "Brian T.Schellenberger" <bts@babbleon.org>, Lars Eggert <larse@ISI.EDU>, "Rogier R. Mulhuijzen" <drwilco@drwilco.net>, freebsd-hackers@FreeBSD.ORG Subject: Re: A weird disk behaviour Message-ID: <Pine.BSF.4.21.0203061052220.37321-100000@InterJet.elischer.org> In-Reply-To: <Pine.SOL.4.21.0203061209250.6633-100000@onyx>
next in thread | previous in thread | raw e-mail | index | archive | help
disks don't work in 512 byte blocks. they work inTRACKS these days.. if you ask for an entire track to be written, that is almost certainly quicker than if you ask for every 2ns block in that track to be written because the second option requires that it read the track first. ALso the seek may trigger code that asks the drive to start syncing to disk while it may hold off doing so if you do a sequential write. Just some ideas.. On Wed, 6 Mar 2002, Zhihui Zhang wrote: > > > On Wed, 6 Mar 2002, Peter Edwards wrote: > > > Zhihui Zhang wrote: > > > > <snip> > > > > > ... I also do not read anything during the partial block write, > > > and I think the disk controller should not do that either. > > > > If you do a partial block write, surely at some point the block must be read > > in order to preserve that segment of data you are _not_ overwriting? > > First off, I am not writing through any file system. I access the raw > device directly. Secondly, the bytes written are always a multiple of 512 > bytes. If one sector is the I/O unit of a disk controller, why should it > read anything to prevent overwritten? > > -Zhihui > > 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?Pine.BSF.4.21.0203061052220.37321-100000>