cheung@vu-vlsi.Villanova.EDU (Wilson Cheung) (01/27/89)
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. As far as I can tell FFS with this setting seemed just a slow as AmigaDos format. Would this limitation on MaxTransfer be the cause of an FFS that offers no speed improvement? or is it something else. Anyway why exactly would a driver have problems if MaxTransfer was set too high? Wilson Cheung
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (01/29/89)
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. The best performance is had on FFS by using no MaxTransfer entry at all. MaxTransfer is a limiting number, and no entry for it allows the file system to ask for as much data as it wants at a time. MaxTransfer is only required if the driver cannot handle unlimited size data requests. >Unfortunately the driver for my hard disk will only permit a MaxTranser of 512K 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? >As far as I can tell FFS with this setting seemed just a slow as AmigaDos >format. Would this limitation on MaxTransfer be the cause of an FFS that >offers no speed improvement? or is it something else. Absolutely. FFS gains most of its speed improvement by allowing the file system to request data from contiguous sectors in large chunks. Without MaxTransfer limitations, the data portion of a large file (say 400K) might be loaded in anywhere from 1 read request and up, depending on the physical location of the 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 requests). By the way, the maxTransfer value in the mountlist specifies BYTES, not blocks. > Anyway why exactly would a driver have problems if MaxTransfer was >set too high? A controller is usually limited by the number of blocks it can accept as a length parameter. The driver software, if it asks for more than this from the hardware, will either get an error, or will transfer a number of byte somewhat less than asked for; <bytes requested> modulo <maximum hardware allows>. A driver, in order to make best use of the FFS, must accept any size transfer request, and break it down into chunks that the hardware can handle, do them, and only then must it tell the requesting program that the transfer has completed. This method will make the best of the hardware speed, while making the process transparent to the file system. The only recommendation I can think of is to wait for an upgrade to the driver, 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 -- 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 | +----------------------------------------------------------------------+
leyse@voltron.SRC.Honeywell.COM (Todd Leyse) (01/31/89)
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? >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? >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 Enquiring minds want to know... Todd C Leyse MN65-2100 Honeywell Systems and Research Center Voice: (612)782-7380 Snail: 3660 Technology Dr., Minneapolis, MN 55418 Amiga: Not Available yet Internet: leyse@moon.honeywell.com UUCP: leyse@srcsip.uucp Bang: {umn-cs,ems,bthpyd}!srcsip!leyse
disd@hubcap.UUCP (Gary Heffelfinger) (02/01/89)
From article <2188@van-bc.UUCP>, by lphillips@lpami.wimsey.bc.ca (Larry Phillips): > 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. > > 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? [Assuming for the moment that he meant 512 and not 512K] I'll bet large sums that he's running the Pacific Periph. Overdrive. I've been running at this level, because that's all the driver software will take. (I assume that it's the software that's the problem.) The system will guru when loading executables, if the MaxTransfer is set higher than 1 block at a time. > The only recommendation I can think of is to wait for an upgrade to the driver, > 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. Marginal in r/w speed, true. Directories are still clocking in at ~100 files/sec according to Diskperfa. Gary -- Gary R Heffelfinger - Not speaking for Clemson University disd@hubcap.clemson.edu -- FIX the Holodeck -- Furman Paladins --- National Champs!!
jwright@atanasoff.cs.iastate.edu (Jim Wright) (02/01/89)
In article <4263@hubcap.UUCP> disd@hubcap.UUCP (Gary Heffelfinger) writes: >[Assuming for the moment that he meant 512 and not 512K] > >I'll bet large sums that he's running the Pacific Periph. Overdrive. I've been >running at this level, because that's all the driver software will take. >(I assume that it's the software that's the problem.) The system will >guru when loading executables, if the MaxTransfer is set higher than 1 >block at a time. This is not a problem with the Overdrive (at least not mine). I've had it up to 1,000,000 with no problems, but also no gain in speed. I currently use about 40,000(?). (I'm at home, it's at work.) Periodic calls to Pac. Per. indicate that the autobooting daughterboard with updated drivers has yet to be released to them by the developing engineer. This is the upgrade promised for the end of the year. I thought they meant last year. :-)
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (02/01/89)
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 | +----------------------------------------------------------------------+
jesup@cbmvax.UUCP (Randell Jesup) (02/03/89)
In article <2197@van-bc.UUCP> lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes: >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. Actually, you also get the benefit of much faster directory listings, since FFS sorts by cylinder the hash chains to reduce head movement. -- Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup