Return to BSD News archive
Xref: sserve comp.unix.bsd:12889 comp.os.386bsd.development:1395 comp.os.386bsd.bugs:1759 comp.os.386bsd.apps:637 comp.os.386bsd.questions:6650 comp.os.386bsd.misc:1420 Newsgroups: comp.unix.bsd,comp.os.386bsd.development,comp.os.386bsd.bugs,comp.os.386bsd.apps,comp.os.386bsd.questions,comp.os.386bsd.misc Path: sserve!cserve.cs.adfa.oz.au!wkt From: wkt@cserve.cs.adfa.oz.au (Warren Toomey) Subject: Re: [RFD] Election of a new Moderator Message-ID: <1993Nov10.055427.3178@sserve.cc.adfa.oz.au> Sender: news@sserve.cc.adfa.oz.au Organization: Australian Defence Force Academy References: <jmonroyCG7w9q.6s2@netcom.com> Date: Wed, 10 Nov 1993 05:54:27 GMT In article <jmonroyCG7w9q.6s2@netcom.com>, jmonroy@netcom.com (Jesus Monroy Jr) writes: |> RFD |> Request For Discussion |> Election of a new moderator I'm a 386bsd person, and Chris has helped me work out some deficiencies with my notices about the news archive on minnie. I haven't seen anybody complaining about the situation. Why don't you collect email with opinions about the situation, and post a summary (and I mean summary) to the misc newsgroup? Warren Toomey wkt@csadfa.cs.adfa.oz.au #! rnews 2958 sserve.cc.adfa.oz.au Newsgroups: comp.os.386bsd.questions Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!headwall.Stanford.EDU!nntp.Stanford.EDU!leland.Stanford.EDU!yergeau From: yergeau@leland.Stanford.EDU (Dan Yergeau) Subject: Re: DISK LIGHT HANG !#@*&!!! Message-ID: <1993Nov9.185303.18610@leland.Stanford.EDU> Sender: news@leland.Stanford.EDU (Mr News) Organization: DSG, Stanford University, CA 94305, USA References: <1993Nov3.190751.17591@sifon.cc.mcgill.ca> <1993Nov8.015518.23306@news.qut.edu.au> <hastyCG75y8.730@netcom.com> Date: Tue, 9 Nov 93 18:53:03 GMT Lines: 58 Just a few additions... In article <hastyCG75y8.730@netcom.com>, hasty@netcom.com (Amancio Hasty Jr) writes: |> The bsd drivers don't use DMA for wd-type drives (MFM, RLL, ESDI, IDE). |> Many times the geometry layout of the disk is not optimized sometimes |> you can get a four fold improvement by just properly fine tuning your |> file system. A nice item for a FAQ. The "reported" geometry with smart drives (IDE or SCSI) is often not the "physical" geometry. Many newer drives do not have a constant number of sectors/track across all of the cylinders. This allows the manufacturer to optimize the use of density by using more sectors/track on outer cylinders and fewer on inner cylinders. Physical seeks may be necessary within the same virtual track. Many drives also divide platters into virtual heads to keep the number of cylinders down so DOS/BIOS will work with them. This may cost half a rotational latency (8 ms @ 3600 RPM) instead of a track-to-track movement w/settle (~2-3 ms). These two effects tend not to be too great, and the presence of a track buffer on the disk can almost eliminate them. In any case, using the largest block/fragment size for filesystem is almost always a good idea. |> There is a new generation of scsi disk drives with higher RPM be in the |> look out for them. I think that IBM is selling one a 1GB with 5400 RPM and |> I saw listed here in Silicon Valley for $1000. |> |> If memory does not failed the more traditional scsi drives are about 3600 RPM. Not only SCSI, but also IDE. Driver manufacturers slap either a SCSI or IDE interface onto the same drive. 5400 RPM is not the fastest out there. There are several 7200 RPM drives on the market. You should also look at physical sectors/track, if available, to get an idea of peak bandwidth. A 5400 RPM drive using a RLL encoding scheme as the media encoding may have a higher bandwidth (due to the potential 1.5 times more sectors/track) than a 7200 RPM drive using a MFM encoding scheme, but the 7200 RPM drive will have a lower rotational latency. BYTE reviewed quite a few hard drives a couple of months back. There was some technical data that is not easily available elsewhere. -- Dan Yergeau You are in a twisty little passage yergeau@gloworm.Stanford.EDU of standards, all conflicting. #include <std.disclaimer>