Return to BSD News archive
Newsgroups: comp.os.386bsd.development Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!elroy.jpl.nasa.gov!swrinde!cs.utexas.edu!uunet!math.fu-berlin.de!xlink.net!subnet.sub.net!flatlin!bad From: bad@flatlin.ka.sub.org (Christoph Badura) Subject: Re: Has anybody tried to add B_ORDER in UFS and disk device driver? Date: Thu, 21 Oct 1993 23:21:33 GMT Message-ID: <CF9svz.BCB@flatlin.ka.sub.org> References: <29v4tl$9er@acsc.com> Organization: Guru Systems/Funware Department Lines: 37 In <29v4tl$9er@acsc.com> jerry@acsc.com (Jerry Chen) writes: >The paper by Larry McVoy and Steve Kleiman >"Extent-like Performance from a UNXI File System", USENIX winter '91 >mentions that if we add a flag B_ORDER in the buf struct and the >disk device driver does not reorder the bufs upon seeing this flag, then >we do not have to always write synchronously in certain directory operations. I ironed something a bit more secure than that out last night. This will go real easy into the code. :-) >That is, if we always put the read/write request at the end of the request queue >in the disk device driver when we see this flag (which can be part of the >b_flags in buf struct) turned on, then, we do not have to have so many bwrite() >in UFS. Actually this is a rather suboptimal approach in handling this. I have a better idea. >This should improve the performance for commands like 'rm *'. If you put the ordered writes at the end of the disk queue (and of course you can't put later blocks before an ordered) I'd doubt that you would see much of an improvement. > Of course, I realize that every disk >driver must support this feature before we can change the code in UFS. Actually disksort() was intended to make this sort of modification independent of the disk drivers. -- Christoph Badura --- bad@flatlin.ka.sub.org -- +49 721 606137 Wer soll denn die Automatik bedienen, wenn die sich nicht per Funk melden. -- Cliff Allistair McLane