Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!gatech!hubcap!ncrcae!ncrlnk!uunet!van-bc!resrch From: lphillips@lpami.wimsey.bc.ca (Larry Phillips) Newsgroups: comp.sys.amiga Subject: Re: FFS with 512 byte buffers Message-ID: <2197@van-bc.UUCP> Date: 1 Feb 89 14:55:12 GMT Sender: resrch@van-bc.UUCP Lines: 103 In <15807@srcsip.UUCP>, leyse@voltron.SRC.Honeywell.COM (Todd Leyse) writes: >In article <2188@van-bc.UUCP> lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes: >>In <2144@vu-vlsi.Villanova.EDU>, cheung@vu-vlsi.Villanova.EDU (Wilson Cheung) writes: >>> I've been hearing people getting satisfactory results with FFS using >>>a 32K setting for MaxTransfer. > >>>Unfortunately the driver for my hard disk will only permit a MaxTranser >>>of 512K bytes. > > ^^^^^^^^^^ Am I missing something? Isn't 512K bytes enough? > Which is correct - the subject line or the article? Hmm... well, I admit I missed the 'K' on the end of that figure. I read it as 512 bytes. However, the rest of the posting indiceted that he was getting approximately the same performance as he did under the old file system, so the figure was probably 512 bytes. >>That is unfortunate. Are you sure about the 512 bytes figure? I have seen a >>number of figures for different products, but none as low as this. What >>driver/controller are you running? > >I don't know much about it either but this sounds wrong. Isn't the new >FFS similar to UN*X's FFS? Does it use 4096 byte blocks whenever >possible instead of 512 byte blocks? Either? Hmm... well, I do know quite a bit about it. You are confusing block size with MaxTransfer. Blocks are still 512 bytes, with all data blocks now containing 512 bytes of data. Under the old file system, a data block contained 488 bytes of data, with the other 24 bytes being overhead in the form of checksums, pointers, and so on. >>sectors containing it. With MaxTransfer set to 512 bytes, it will take the same >>number of requests to load as it would have under the old file system (800 > >>[deletion of paragraphs without 512 in them ;-) ...] > >>or if that will not happen, change to another controller. Runninf FFS at a >>maxTransfer of 512 bytes offers only marginal improvement in speed and drive >>data capacity. >>-larry To illustrate the workings and the value of the FFS, and the results of setting MaxTransfer to 512, let's assume a file that is stored as follows (data blocks only): Block # within file : 1 2 3 4 5 6 7 Block # on the drive: 100 101 102 200 201 202 203 Notice that the file is fragmented physically on the disk. The file system looks at what it has to read, and asks for as much data as it can at any given time, while keeping an eye on MaxTransfer to make sure it does not ask for more data than the driver can handle. Under the two different file systems, the blocks would be read with the following IO requests, provided that MaxTransfer is not specified, or that it is specified as being 2048 bytes or greater: Old File System New File System --------------- --------------- Block length read Block length read ----- ----------- ----- ----------- 100 512 101-102 1536 101 512 200-203 2048 102 512 200 512 201 512 202 512 203 512 The new file system eliminates much of the controller/drive overhead of selection and command/status passing, since there are fewer IO requests. Most controllers will accept a read request of more than one sector, and does not require reselection or verification of successful reads after each sector. In addition, you could save time because of being able to reduce the interleave value. Most importantly, in the case of the OFS, the data was not contiguous. The file system read it into its own buffer, stripped off the overhead bytes, and then sent the 488 data bytes to the final destination. Under FFS, the data can go directly to the final destination, further reducing time spent, and having more likelihood of allowing you to be able to reduce the interleave. The only benefit to be had with using FFS and having a MaxTransfer of 512 bytes is that you will gain 24 bytes per data block, and that only one transfer is needed, to the final destination. This is, as I mentioned in the posting, a marginal improvement. >Enquiring minds want to know... Always glad to oblige an enquiring mind... >Todd C Leyse MN65-2100 Honeywell Systems and Research Center -larry -- Frisbeetarianism: The belief that when you die, your soul goes up on the roof and gets stuck. +----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca or uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 | +----------------------------------------------------------------------+