Return to BSD News archive
Xref: sserve comp.os.386bsd.misc:4364 alt.folklore.computers:69549 Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!msunews!uwm.edu!cs.utexas.edu!swrinde!pipex!uunet!zib-berlin.de!rs1-hrz.uni-duisburg.de!rrz.uni-koeln.de!RRZ.Uni-Koeln.DE!RRZ.Uni-Koeln.DE!news From: se@fileserv1.MI.Uni-Koeln.DE (Stefan Esser) Newsgroups: comp.os.386bsd.misc,alt.folklore.computers Subject: Re: BSD sluggish compared to Linux? Date: 10 Dec 1994 17:38:57 GMT Organization: Institute of Nuclear Physics, University of Cologne, Germany Lines: 86 Distribution: world Message-ID: <3ccp3hINN36ao@rs1.rrz.Uni-Koeln.DE> References: <3am248$7kv@itu1.sun.ac.za> <3ao31t$9fo@itu1.sun.ac.za> <KSTAILEY.94Dec6120735@leidecker.gsfc.nasa.gov> NNTP-Posting-Host: fileserv1.mi.uni-koeln.de In article <KSTAILEY.94Dec6120735@leidecker.gsfc.nasa.gov>, kstailey@leidecker.gsfc.nasa.gov (Kenneth Stailey) writes: |> If you have SCSI disks under NetBSD you can improve the performance by |> [1] setting maxcontig to at least 8 (default is 1) to enable clustering |> (this can be using "tunefs") |> [2] setting rotational delays to 0 (must use newfs, sigh) |> [3] setting number of rotational positions to 1 (ditto) |> |> If you use newfs you must of course backup & reinstall everything. |> The options to get all three are "-a 8 -d 0 -n 1". |> |> This probably applies to other BSD's too. These are the defaults in FreeBSD-2.0 ... (But before it was "-a 0 -d 3 -n 8".) But there is one problem with [3] above: If the file system is in need of a free disk block, and the one just after the last block allocated to the file in question is not free, then it will choose any block in the next rotational position. Now, if there is only one rotational position, this will make the FS use any free block within a few cylinders at random (keep in mind, that many drives use virtual geometries with <1024 cylinders, while the drive physically has 2000 to 3000 or more ...). This leads to many unneccessary "short seeks" and rotational delays. |> The problem is that you don't really know with any certainty exactly |> where a given disk block is on a SCSI drive since you only talk to the |> controller. I guess with ZBR disks being quite standard, the whole rotational position optimisation code should be disabled for SCSI (and IDE) drives. If the block allocator function would just look for the next block after the one it failed to allocate, then it would at least not do random seeks, and would in fact often find a free block at short distance (ie. less than next track seek time plus avg. rot. delay). The code change is trivial (I have in fact just commented out all code from line 907 to the 'norot' lable ...): *** sys/ufs/ffs/ffs_alloc.c~ Sat Dec 10 18:08:45 1994 --- sys/ufs/ffs/ffs_alloc.c Sat Dec 10 18:17:27 1994 *************** *** 905,908 **** --- 905,915 ---- goto gotit; } + /* + * if there is only one rotational position, then scan sequentially + * for the next block ... this is better than the code below, which + * will choose a random block within what it believes to be a cylinder + */ + if (fs->fs_nrpos <= 1) + goto norot; /* * check for a block available on the same cylinder This will prefer sequentially laid out files, which makes the SCSI read ahead buffer happy. I'd be happy to discuss this further (it has been a pet peeve of mine for many years now. I guess there will never again be any hard disk drive that offers a predictable sector layout as was common in the time of SMD drives, when this rotational position table code was a major step forward ...). STefan -- Stefan Esser Internet: <se@ZPR.Uni-Koeln.DE> Zentrum fuer Paralleles Rechnen Tel: +49 221 4706010 Universitaet zu Koeln FAX: +49 221 4705160 Weyertal 80 50931 Koeln