L.Chung@ee.surrey.ac.uk (L N Chung) (05/23/91)
Which hard disk formatting program can do a low level format on IDE drives? Which one will hand SCSI and ESDI drives ? -------------------------------------------------------------------------- L.N. Chung Dept of Elec. Eng, University of Surrey, (ees1lc@ee.surrey.ac.uk) Guildford, Surrey, GU2 5XH. UK. (l.chung@ee.surrey.ac.uk) PHONE: +44 483 571281 FAX: +44 483 34139
stone@cunixb.cc.columbia.edu (Glenn Stone) (05/25/91)
In article <1991May22.172536.10283@EE.Surrey.Ac.UK> L.Chung@ee.surrey.ac.uk (L N Chung) writes: > >Which hard disk formatting program can do a low level format on IDE drives? >Which one will hand SCSI and ESDI drives ? They say you can't low-level format IDE drives yourself. The "Letters" in the latest Byte magazine discusses why. ------------------------------------------------------------------------- Glenn Stone BITNET: stone@cunixc Columbia University INTERNET: stone@cunixb.cc.columbia.edu -------------------------------------------------------------------------
stone@cunixb.cc.columbia.edu (Glenn Stone) (05/28/91)
L.Chung@ee.surrey.ac.uk (L N Chung) writes: >> >>Which hard disk formatting program can do a low level format on IDE drives? >>Which one will hand SCSI and ESDI drives ? > >They say you can't low-level format IDE drives yourself. The "Letters" >in the latest Byte magazine discusses why. > -Subject: Re: Low Level HD Formatting Software -Newsgroups: comp.sys.ibm.pc.hardware,comp.sys.ibm.pc.misc,comp.os.msdos.apps -In-Reply-To: <1991May25.131542.11052@cunixf.cc.columbia.edu> -References: <1991May22.172536.10283@EE.Surrey.Ac.UK> -Organization: NCSU Computing Center -Cc: - -Can you paraphrase why for us non-byte readers. - -rdkeys@ccvr1.cc.ncsu.edu - Roger Alford had an article on the IDE interface in the March issue and answers a letter in the June issue. His explanation is that the only reasons to low-level format are to set the interleave factor and map bad sectors. IDE drives only run on a 1:1 interleave, and the bad sectors can be marked in the factory. While some people advise periodic low-level formatting to freshen up the sector markers, he claims that fading sector marks aren't really the cause of mis-reads; misaligned heads are. ------------------------------------------------------------------------- Glenn Stone BITNET: stone@cunixc Columbia University INTERNET: stone@cunixb.cc.columbia.edu -------------------------------------------------------------------------
mbb@cbnewsb.cb.att.com (martin.brilliant) (05/28/91)
From article <1991May28.021833.5303@cunixf.cc.columbia.edu>, by stone@cunixb.cc.columbia.edu (Glenn Stone): > > ... While some people advise > periodic low-level formatting to freshen up the sector markers, he > claims that fading sector marks aren't really the cause of mis-reads; > misaligned heads are. Exactly. I thought the reason for low-level formatting an aging drive was to realign the tracks with the misaligned heads, because that's easier and safer than opening up the drive to realign the heads with the tracks. True? or fantasy? Marty marty@hoqax.att.com hoqax!marty Martin B. Brilliant (Winnertech Corporation)
mleech@bnr.ca (Marcus Leech) (05/28/91)
In article <1991May28.133950.14789@cbfsb.att.com>, mbb@cbnewsb.cb.att.com (martin.brilliant) writes: |> Exactly. I thought the reason for low-level formatting an aging drive |> was to realign the tracks with the misaligned heads, because that's |> easier and safer than opening up the drive to realign the heads with |> the tracks. True? or fantasy? Exactly. The problem with these wizzy new sealed-hda-and-smaller-than-a- washing-machine drives is the inability to do what used to be routine maintenance, which included occasional non-destructive head realignment. There used to be "alignment" packs that you'd load onto the drive, and with some other whizzo electronics, you could tweak the head alignment. This procedure is usually only necessary when installing a new drive, and perhaps every 4 or 5 years thereafter. -- Marcus Leech, 4Y11 Bell-Northern Research |opinions expressed mleech@bnr.ca P.O. Box 3511, Stn. C |are my own, and not VE3MDL@VE3JF.ON.CAN.NA Ottawa, ON, CAN K1Y 4H7 |necessarily BNRs
wlsmith@valve.heart.rri.uwo.ca (Wayne L. Smith) (05/28/91)
In article <1991May28.133950.14789@cbfsb.att.com> mbb@cbnewsb.cb.att.com (martin.brilliant) writes: >> periodic low-level formatting to freshen up the sector markers, he >> claims that fading sector marks aren't really the cause of mis-reads; >> misaligned heads are. > >Exactly. I thought the reason for low-level formatting an aging drive >was to realign the tracks with the misaligned heads, because that's >easier and safer than opening up the drive to realign the heads with >the tracks. True? or fantasy? > I thought that the heads, which would creep, would lay down data which would be skewed in relationship to the sector id data (on the same track as the data). Sector id data, which is only created during a low-level format, would eventually become unreadable as the heads crept. But as the heads crept, the data that they read/wrote would always be directly underneath them. A periodic low-level format sounds like a good way to solve this problem, IF this really happens...
amichiel@rodan.acs.syr.edu (Allen J Michielsen) (06/01/91)
<1991May28.133950.14789@cbfsb.> mbb@cbnewsb.cb.att.com (martin.brilliant) >From<1991May28.021833.5303@>, by stone@cunixb.cc.columbia.edu (Glenn Stone): >> periodic low-level formatting to freshen up the sector markers, he >> claims that fading sector marks aren't really the cause of mis-reads; >> misaligned heads are. (In reference to a magazine article he was quoting) >Exactly. I thought the reason for low-level formatting an aging drive >was to realign the tracks with the misaligned heads, ... I tend to agree. When you take a older hard drive and move it on a axis it tends to 'lose' format and this should only be due to this problem. The drive mfg's say that they are now designing drives with more/any/all axial locationing designed into them. (meaning you can stand it on end or move it between on end on on side without any problems) The NEW design drives, I have used, seem to support this claim, BETTER than older designed drives. I have read in several sources that the actual problem requiring LLF is most commonly due to data creep. This is where the controller/drive actuall wipe out the LLF marks due to miscommunication between the 2 of them, and due to HOW the system determines WHEN to start writing data bits. Actually the case is that writing data is rather almost done on a by guess by golly basis, and sometimes the assumptions aren't perfect. This type of problem is nonexistant on ide, scsi, & esdi drives due to fundamental design differences in HOW the controller works (after all all 3 of these 'standards' were made AFTER the st506 was well written in stone and has millions of hours of field tests by users). Actually IDE is only a st506 mfm or rll drive with much more of the smarts of the controller included in/on the drive, and much more like a data/address buffer i/o card for a controller. However, this means that the real 'controller' part is not just a standard generic interface, but hopefully one selected/designed to be perfectly mated to the drive. It also means that the cable lenght and corrected capicitance for signals is known with absolute certainty with much smaller error rates/lengths. However, saying that new designs have eliminated future, end of product alignment problems AND redesign to reduce/eliminate 'bit migration' is no excuse for NOT providing the end user with the ABILITY to LLF to their hearts content. Don't worry, these drives CAN be formatted by the end user with almost every available (compatible) controller. The software drivers are missing, and in time will become available to everybody. Don't worry, because you won't need them for several years probably anyway. The lucky few that hopped on at the begining will be the ones to pave the way, and make the drive mfg's sorry for their mistake. al -- Al. Michielsen, Mechanical & Aerospace Engineering, Syracuse University InterNet: amichiel@rodan.acs.syr.edu amichiel@sunrise.acs.syr.edu Bitnet: AMICHIEL@SUNRISE