Path: utzoo!attcan!uunet!mcsun!ukc!dcl-cs!aber-cs!athene!pcg From: pcg@cs.aber.ac.uk (Piercarlo Grandi) Newsgroups: comp.unix.internals Subject: Re: File system performance Message-ID: Date: 7 Nov 90 17:31:00 GMT References: <267@srchtec.UUCP> <1990Oct19.130404.25352@nstar.uucp> <1990Oct31.120401.4814@nstar.uucp> <1990Oct31.212543.28245@ico.isc.com> <1990Nov05.031547.11369@scuzzy.in-berlin.de> Sender: pcg@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 61 Nntp-Posting-Host: odin In-reply-to: src@scuzzy.in-berlin.de's message of 5 Nov 90 03:15:47 GMT On 5 Nov 90 03:15:47 GMT, src@scuzzy.in-berlin.de (Heiko Blume) said: src> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: pcg> Note that the gap should be dependent on the *CPU* and ther kernel pcg> speed, not on the drive (for a given rotational speed). The pcg> filesystem gap is there to compensate for interrupt and processing pcg> time. src> sure, but how do i determine a optimal gap for a given system. src> since i have three different disk drives varying from real-slow to fast src> this should be very interesting! that is, there are between 32 and 51 src> sectors/track on those and the drives using zone bit recording have src> more on the outer tracks. the mkfs man page and the admin guide src> tell near to nothing about it. This is a real black art... :-(. The number of sectors per track is irrelevant (excep that you want a gap that is relatively prime). Zone recording can be ignored by taking the values for the worst case. What remains is the time taken by the kernel, CPU, controller chain to field back-to-back sector requests. Not easy to do without powerful technology. In practice this will work, even if it is a slow method and requires dedicating the machine to the tests: 1) While in single user state choose any expendable partition. 2) mkfs it for some value of the gap -- to speed up things don't bother to create a filesystem as large as the partition. Say that five MB is ok. 3) mount that partition. 4) record the *elapsed* time it takes to write a large file to that partition. Say two to four MB (larger does not matter -- smaller is too quick). 5) umount the partition (this is *essential*). 6) remount the partition. 7) record the *elapsed* time it takes to reread that large file. 8) umount the partition 9) choose a different value for the gap and restart at 2). Look at the graph of times taken to read and write vs. the gap size. Choose the gap that gives the best times -- it is usually fairly obvious which one to choose (give read performance priority over write performance, unless you have specfial reasons). A bit larger will usually be safer and more portable and will not worsen performance significantly. A bit smaller will worsen performance drastically. It usually pays to tune the gap. -- Piercarlo "Peter" Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk