nancy@resonex.UUCP (Nancy Blachman) (02/21/85)
Has any one done a study on the effectiveness of disk formatting
programs? Which formatting program have you found to be most
effective? I have tried formatting disks with the Unix 4.2 format
routine. It took me 13 hours on a 400 mbyte disk. I have also
formatted Eagles using the Emulex format routine which takes 2 1/2
hours. Naturally I prefer bringing down the system for 2 1/2 hours
rather than 13. But is the Emulex format routine any good?
--
/\//\//\//\//\//\//\//\//\//\//\//\//\//\//\//\//\//\//\//\//\//\//\//\//\//\/
Nancy Blachman UUCP: {allegra,hplabs,ihnp4,ucbvax!sun}!resonex!nancy
(408)720 8600 x37 ARPA: sun!resonex!nancy@ucbvax.ARPAjim@mcvax.UUCP (Jim McKie) (02/23/85)
In article <232@resonex.UUCP> nancy@resonex.UUCP (Nancy Blachman) writes:
.......... I have tried formatting disks with the Unix 4.2 format
routine. It took me 13 hours on a 400 mbyte disk. I have also
formatted Eagles using the Emulex format routine which takes 2 1/2
hours..............................................................
It's a few weeks since I did an Eagle (but another 6 should arrive in
a couple of weeks. I estimate 3 to 4 hours to format them all under
the 4.2BSD format. But we don't do 'severe burn in', just 'worst-case
media-test'. The disks have been happy with it so far (9 of them).
You didn't say which bus/controller/cpu you're using, but these figures
are for Vax 11/750 with Emulex SC750.
--jimthomas@utah-gr.UUCP (Spencer W. Thomas) (02/25/85)
In article <478@mcvax.UUCP> jim@mcvax.UUCP (Jim McKie) writes: >In article <232@resonex.UUCP> nancy@resonex.UUCP (Nancy Blachman) writes: > .......... I have tried formatting disks with the Unix 4.2 format > routine. It took me 13 hours on a 400 mbyte disk. I have also > formatted Eagles using the Emulex format routine which takes 2 1/2 > hours.............................................................. > >But we don't do 'severe burn in', just 'worst-case media-test'. I think the 'severe burn in' is well worth while. It finds many more potentially bad spots than the other tests. Given that any disk (Eagles included -- from personal experience) will eventually "develop" new bad spots, a little extra time up front is worth a lot of agony later on. Also, adding new bad blocks to the list is a real pain -- the list of bad blocks is kept in sorted order, so when you add a block to it, all the ones after it must be shifted down one (i.e., you need to copy the contents of the forwarded block to the next physical block on the disk). -- =Spencer ({ihnp4,decvax}!utah-cs!thomas, thomas@utah-cs.ARPA) "A sharp tongue is the only edge tool that grows keener with constant use" - Washington Irving
karl@cygnet.CYGNETSYSTEMS (Karl Danz) (03/02/85)
[] >Also, adding new bad blocks to the list is a real pain -- the list of >bad blocks is kept in sorted order, so when you add a block to it, all >the ones after it must be shifted down one (i.e., you need to copy the >contents of the forwarded block to the next physical block on the disk). We were bitten by this same problem (on an Eagle as well). I retched at the thought of all that manual shifting and instead made the inclosed one line change to /sys/vax/dkbad.c (4.2BSD). I suppose it doubles the average time spent looking up replacement blocks, but somehow I doubt that's our major performance bottleneck! ------------------------------------------------------- RCS file: RCS/dkbad.c,v retrieving revision 1.1 diff -r1.1 dkbad.c 25c25 < if (blk < bblk || bblk < 0) --- > if (bblk < 0) ------------------------------------------------------- -- Karl Danz Cygnet Systems ...!hplabs!cygnet!karl (408) 773-0770