thad@cup.portal.com (Thad P Floryan) (06/29/89)
Yong Ren asks about replacing the stock 20MB Miniscribe HD in his UNIXPC with a Seagate ST251-1 ... The ST251-1 installs easily. No need to change power supply, cover, etc. I've done several of these installations for friends and all went smoothly. HOWEVER: in light of the general problem of Seagates (ref. the "non-spin" due to overlubrication of the platters during assembly causing "stiction"), and considering the price differential of an ST251-1 vs., say, a Miniscribe 3085, you get more value for your $$$, more storage, and faster access for only about $200 more (NOT including the cost of a WD2010 chip (approx. $45)). Using the prices quoted in various dealers' ads in the daily San Jose Mercury News (Silicon Valley) as an example, the Seagate ST251-1 is around $390 and the Miniscribe 3085 is $590. Additionally: Seagate ST251-1 Miniscribe 3085 Heads 6 7 Cylinders 820 1170 Access time (per mfr). 28 mS 22 mS MB, formatted (std, 17 sec/trk) 42.8 71.2 MB, formatted (UNIXPC, 16 sec/trk) 40.3 67.1 (ignoring the spare sec per track) MB, avail on UNIXPC assuming a 5MB 35.3 62.1 swap partition (multiuser standard) Note that you'd need to change the WD1010 HD controller chip to a WD2010, and format using the "new" diagnostic disk to get full utilization of the 3085. Some other choices (also NOT requiring a power supply or cover change) include some 3.5" HDs with capacities up to 100MB. Thad Floryan [ thad@cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad ]
ebh@argon.UUCP (Ed Horch) (07/01/89)
In article <19995@cup.portal.com> thad@cup.portal.com (Thad P Floryan) writes: >MB, formatted (std, 17 sec/trk) 42.8 71.2 > >MB, formatted (UNIXPC, 16 sec/trk) 40.3 67.1 >(ignoring the spare sec per track) What does the Unix PC do with that extra sector? Is that how it remaps bad blocks? -Ed
kevin@kosman.UUCP (Kevin O'Gorman) (07/01/89)
In article <701@argon.UUCP> ebh@argon.UUCP (Ed Horch) writes: >In article <19995@cup.portal.com> thad@cup.portal.com (Thad P Floryan) writes: >>MB, formatted (UNIXPC, 16 sec/trk) 40.3 67.1 >>(ignoring the spare sec per track) > >What does the Unix PC do with that extra sector? Is that how it >remaps bad blocks? Yes, the 17th sector is used for spares. Note that a sector is half a logical block, so this arrangement makes some sense: in the normal course of things, almost all blocks are read as two consecutive sectors on the same track. Also note, that when you specify bad blocks by logical block number, the system pretty much has to assign alternates for both of the pysical sectors.
thad@cup.portal.com (Thad P Floryan) (07/02/89)
Re: Ed Horch's question about my table showing HD capacities at both 17 and 16 sectors per track for the UNIXPC ... Yes, that appears to be how the bad blocks are "spared out" on the UNIXPC. The system (at least 3.51) uses 1K blocks and lays down 8 of those (16 sectors) per track. From one point of view, we're losing 1/17 the capacity of our HDs on the UNIXPC because of this scheme (scam? :-) I've never seen a (new) HD with more than, say, 20 factory-reported bad sectors yet (assuming a mongo Maxtor with 312,120 sectors), a LOT are being "wasted." Thad Floryan [ thad@cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad ]
jbm@uncle.UUCP (John B. Milton) (08/08/89)
In article <701@argon.UUCP> ebh@argon.UUCP (Ed Horch) writes: >In article <19995@cup.portal.com> thad@cup.portal.com (Thad P Floryan) writes: >>MB, formatted (std, 17 sec/trk) 42.8 71.2 >> >>MB, formatted (UNIXPC, 16 sec/trk) 40.3 67.1 >>(ignoring the spare sec per track) > >What does the Unix PC do with that extra sector? Is that how it >remaps bad blocks? Yes, that's how "it" does it. 1/17th of the total formatted disk capacity is thrown away to make bad block mapping easier. If there is more than one bad sector on a track, it uses the 17th sector from another track. Below is the output from "iv -vt /dev/rfp000", which shows all the formatting info from the VHB (Volume Home Block), as well as a dump of the bad block table, which I sorted after including in this article, careful examination will show that this bad block table was not created entirely on the first pass. One could argue that a better bad block scheme should have been developed, but this one simplified other problems (1k "driver" logical blocks), and runs fairly quickly. Winchester disk Volume Name: WINCHE 917 Cylinders. 9 Heads per Cylinder. There are 17 Physical Sectors (of 512 bytes) per Track. 153 Physical Sectors per Cylinder, 140301 Physical Sectors per Disk. There are 8 Logical Blocks (of 1024 bytes) per Track. 72 Logical Blocks per Cylinder, 66024 Logical Blocks per Disk. The Step Rate supplied to the Controller is 0. Partition 0: start Track=0, size (in Blocks)=72 Partition 1: start Track=9, size (in Blocks)=5000 Partition 2: start Track=634, size (in Blocks)=60952 Loader starts at Block 2 (size=23 Blocks). Bad Block Table starts at Block 1 (size=1 Blocks). Cylinder 175, Track 3, Sector 4, uses Track 3, Sector 16 as Alternate. Cylinder 352, Track 2, Sector 0, uses Track 3, Sector 16 as Alternate. Cylinder 352, Track 2, Sector 1, uses Track 1, Sector 16 as Alternate. Cylinder 352, Track 2, Sector 12, uses Track 2, Sector 16 as Alternate. Cylinder 359, Track 4, Sector 0, uses Track 3, Sector 16 as Alternate. Cylinder 359, Track 4, Sector 1, uses Track 6, Sector 16 as Alternate. Cylinder 359, Track 4, Sector 12, uses Track 4, Sector 16 as Alternate. Cylinder 359, Track 4, Sector 13, uses Track 5, Sector 16 as Alternate. Cylinder 449, Track 6, Sector 12, uses Track 6, Sector 16 as Alternate. Cylinder 510, Track 7, Sector 0, uses Track 8, Sector 16 as Alternate. Cylinder 510, Track 7, Sector 1, uses Track 7, Sector 16 as Alternate. Cylinder 643, Track 6, Sector 1, uses Track 6, Sector 16 as Alternate. Cylinder 763, Track 6, Sector 0, uses Track 6, Sector 16 as Alternate. Cylinder 763, Track 6, Sector 1, uses Track 7, Sector 16 as Alternate. Cylinder 855, Track 8, Sector 0, uses Track 8, Sector 16 as Alternate. Cylinder 855, Track 8, Sector 1, uses Track 0, Sector 16 as Alternate. The Bad Block Table contains 16 entries. John -- John Bly Milton IV, jbm@uncle.UUCP, n8emr!uncle!jbm@osu-cis.cis.ohio-state.edu (614) h:294-4823, w:466-9324; N8KSN, AMPR: 44.70.0.52; Don't FLAME, inform!
res@cbnews.ATT.COM (Robert E. Stampfli) (08/14/89)
> >Yes, that's how "it" does it. 1/17th of the t [ Discussion of the fact that one block per track is unused on the hard disk. ] Question: Are these blocks accessible at all? What if I access the raw device? Could a special driver be written to utilize them? Rob Stampfli att!cbnews!res (work) osu-cis.cis.ohio-state.edu!n8emr!kd8wk!res (home)
gst@gnosys.UUCP (Gary S. Trujillo) (08/15/89)
In article <569@uncle.UUCP> jbm@uncle.UUCP (John B. Milton) writes: > In article <701@argon.UUCP> ebh@argon.UUCP (Ed Horch) writes: > >In article <19995@cup.portal.com> thad@cup.portal.com (Thad P Floryan) writes: > >>MB, formatted (std, 17 sec/trk) 42.8 71.2 > >> > >>MB, formatted (UNIXPC, 16 sec/trk) 40.3 67.1 > >>(ignoring the spare sec per track) > > > >What does the Unix PC do with that extra sector? Is that how it > >remaps bad blocks? > > Yes, that's how "it" does it... Some of you may recall that this article was posted by jbm way back on 3 July. It would appear that there's a problem out on the net that has been affecting virtually all newsgroups (I guess) which results in ancient messages coming back to haunt us. If you preserve your news log files for a long time, the articles would be rejected as duplicates. But I, for one, expire my logs. Anyway, I just thought y'all might like to know. Here are excerpts from some recent traffic in news.admin that discuss the problem: |Path: husc6!mailrus!wasatch!helios.ee.lbl.gov!nosc!logicon.arpa!Makey |From: Makey@LOGICON.ARPA (Jeff Makey) |Newsgroups: news.admin |Subject: Old articles reposted: the saga continues |Summary: Aaaarrrrgggghhhh!!!! |Message-ID: <524@logicon.arpa> |Date: 11 Aug 89 23:36:10 GMT |Organization: Future Procrastinators of America | |It's happening again! Below are the message-ids of 70 articles that |originally appeared about June 30 but have been reposted with a date |of August 8. They all include | |rochester!rit!tropix!moscom!ur-valhalla!uhura.cc.rochester.edu!sunybcs | |in their Path: lines, and none of the articles are in the alt |hierarchy. I find it easier to simply delete the offending files than |to generate local cancel messages for them. | |I wish this would stop. | |--------------------------- cut here ---------------------------- |<1003@tekbspa.UUCP> |<1006@tekbspa.UUCP> |... | :: Jeff Makey | |Department of Tautological Pleonasms and Superfluous Redundancies Department | Disclaimer: Logicon doesn't even know we're running news. | Internet: Makey@LOGICON.ARPA UUCP: {nosc,ucsd}!logicon.arpa!Makey | | |Path: ...!ginosko!uunet!cs.utexas.edu!rutgers!usc!ucsd!nosc!logicon.arpa!Makey |From: Makey@LOGICON.ARPA (Jeff Makey) |Newsgroups: news.admin |Subject: Re: Old articles reposted: the saga continues |Summary: Yet another 100 articles. |Keywords: $&@*%! |Message-ID: <526@logicon.arpa> |Date: 13 Aug 89 06:13:21 GMT |References: <524@logicon.arpa> |Organization: Future Procrastinators of America | |Here's another 100 message-ids of old news that has reappeared with a |date of either July 22 or August 8. These articles all have | | rit!tropix!moscom!ur-valhalla!uhura.cc.rochester.edu | |in theirs paths, which is slightly shorter than another path that was |implicated earlier (rochester was on the left end and sunybcs was on |the right end). This set of 100 articles used about 200,000 bytes of |disk space. I find these articles by grepping through the news spool |area for "tropix!moscom". I have no proof that one of these two sites |is actually responsible, but the technique works for me. | |------------------------- cut here ------------------------------ |<1025@cernvax.UUCP> |<1049@philmds.UUCP> |... BTW, I have confirmed that the path segment quoted in these messages was in fact in the duplicate articles I have received. I also found the problem affecting comp.sources.misc (of all things!). Beware! -- Gary S. Trujillo {linus,bbn,m2c}!spdcc!gnosys!gst Somerville, Massachusetts {ima,stech,wjh12}!gnosys!gst