Path: utzoo!utgpu!watserv1!watmath!att!att!linac!uwm.edu!zaphod.mps.ohio-state.edu!samsung!uunet!mcsun!ukc!dcl-cs!aber-cs!athene!pcg From: pcg@cs.aber.ac.uk (Piercarlo Grandi) Newsgroups: comp.unix.sysv386 Subject: Re: File system performance Message-ID: Date: 2 Nov 90 23:59:45 GMT References: <267@srchtec.UUCP> <1990Oct19.130404.25352@nstar.uucp> <1990Oct31.120401.4814@nstar.uucp> <1990Oct31.212543.28245@ico.isc.com> <1990Nov01.115148.14436@nstar.uucp> Sender: pcg@aber-cs.UUCP Followup-To: comp.unix.internals Organization: Coleg Prifysgol Cymru Lines: 45 In-reply-to: larry@nstar.uucp's message of 1 Nov 90 11:51:48 GMT Note that foloowups have been redirected to comp.unix.internals, because this is a discussion not limited to the 386 case. On 1 Nov 90 11:51:48 GMT, larry@nstar.uucp (Larry Snyder) said: larry> rcd@ico.isc.com (Dick Dunn) writes: rcd> just that the code is cleaner and spends a little less time rcd> fiddling with special cases that turn out not to matter. I suspect rcd> that cylinder groups (present in ufs but not FFS) don't help much; rcd> they may actually be the hindrance that makes the performance rcd> difference. Well, actually the purpose of cylinder groups is to spread out the ilist, and to put related inodes together and nearer the file blocks rooted on them, not to improve IO rates for files; it does not help bandwidth or file-based applications, but it does help interactive performance, i.e. applications that are directory based, and open lots of files with little IO (e.g. 'file *') or of inodes (e.g. 'ls -F'). The real problem with the BSD FFS is that the block/fragment scheme is equivalent to allocating runs of blocks and doing synchronous 8 block read ahead all the time, only it limits the length of the runs to 8, and forces all reads, even random reads, to do 8 blocks of synchronous read ahead. The authors simply did not understand the design principles of the Unix V7 filesystem, and its author's well motivated reluctance to souble the block size to 1024 bytes, and their use of asynchronous read ahead instead. Another win would have been to put the first page of the file just after the inode. larry> The Intel release 4 manuals go to great details to explain the larry> gap/cylinder paramters and their "sample setting" whening making larry> filesystems - but their examples are basically for 3b2 drives larry> (all the way up to a big 72 meg drive). Note that the gap should be dependent on the *CPU* and ther kernel speed, not on the drive (for a given rotational speed). The filesystem gap is there to compensate for interrupt and processing time. -- 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