Return to BSD News archive
Received: by minnie.vk1xwt.ampr.org with NNTP id AA5232 ; Tue, 22 Dec 92 15:00:32 EST Path: sserve!manuel.anu.edu.au!munnari.oz.au!sgiblab!swrinde!cs.utexas.edu!natinst.com!hrd769.brooks.af.mil!hrd769.brooks.af.mil!not-for-mail From: news@hrd769.brooks.af.mil (InterNet News) Newsgroups: comp.unix.bsd Subject: Re: [386BSD] Disklabel for MAXTOR LXT340S Date: 19 Dec 1992 11:50:53 -0600 Organization: Armstrong Lab MIS, Brooks AFB TX Lines: 39 Message-ID: <1gvndtINN8k7@hrd769.brooks.af.mil> References: <1992Dec12.100620.16224@tfs.com> <1992Dec15.165013.18162@prism.poly.edu> <PCG.92Dec18223754@decb.aber.ac.uk> NNTP-Posting-Host: hrd769.brooks.af.mil In article <PCG.92Dec18223754@decb.aber.ac.uk> pcg@aber.ac.uk (Piercarlo Grandi) writes: >Therefore the best bet is to give a bogus geometry, of which the default >Adaptec supplied one is one of the most convenient, being N cylinders of >1MB each, which makes partitioning easier, and abandon all hopes of >doing lowe level optimizations as those done in the BSD filesystem code, >that try to minimize things like rotational latency, which are actually >handled by the LXT340 OS. Note to Ultrastor 24F users with Maxtor 340: When using the 24F in ISA mode (because none of us can get the specs for the controller :-(), it is necessary to use the geometry reported by the controller at boot up. This configuration is neither the physical geometry nor the N * 1Meg geometry, but some third strange geometry. Using any other seems to mess the 340S up rather badly (resulting in inode losses and files overwriting each other). With the geometry exception, this article goes a long way to explain some of the unusual behaviors of the 340S and the Ultrastor card. A public Thank You for an informative article. > >A couple of years ago we had a discussion on this; somebody recently >posted in this newsgroup a patch along the line sof that discussion that >just makes the BSD filesystem code try to keep block sequentially >contiguous if the parameters indicate it is a SCSI disk, with no fancier >layout policy (which are of dubious value anyhow). >-- I think the purpose of the patch was to not do anything (basically) to an SCSI file system, since there is no real way of know what the file system on the disk REALLY looks like. I looked at it and will be incorporating it over the holidays, even though I am using the SCSI disk as if it were an ESDI/IDE drive. >Piercarlo Grandi, Dept of CS, PC/UW@Aberystwyth <pcg@aber.ac.uk> TSgt Dave Burgess NCOIC AL/MIS Brooks AFB, TX