SUMMARY: Hitachi 3.7Gb Drive

From: Anthony Yen (tyen@mundo.eco.utexas.edu)
Date: Wed Mar 24 1993 - 10:12:09 CST


ORIGINAL QUERY
==============

> Date: Fri, 19 Feb 1993 03:08:54 -0600
> X-Mailer: Mail User's Shell (7.2.3 5/22/91)
> To: sun-managers@eecs.nwu.edu
> Subject: Hitachi 3.7Gb Drive
>
> Does anyone have any experience with Hitachi's 3.7Gb drive under SunOS
> 4.1.3? Does it really format out to about 2Gb, or would I actually
> have to partition out a sliver of disk space?
>
> For that matter, I'd be interested in hearing any reports on Hitachi's
> 1.65Gb DK516.
>
> ____
> /ony Yen - tyen@mundo.eco.utexas.edu ... Sail tough
> SPARC SysAdmin - UT/Austin - Economics or go home ... Kowabunga!

SUMMARY
=======

Thanks go out to all who replied:

        "Peter D. Bille" <PETER@andataco.andataco.com>
        Christian Lawrence <cal@soac.bellcore.com>
        Dave Mitchell <D.Mitchell@dcs.sheffield.ac.uk>
        obs!emike@uu2.psi.com (E. Mike Durbin)
        Kenton C. Phillips <kenton@space.mit.edu>
        michael@ts.go.dlr.de (Michael Klein)
        ups!upstage!glenn@fourx.Aus.Sun.COM (Glenn Satchell - Uniq Professional Services)
        celita@taux01.nsc.com
        fallan@baobab.awadi.com.AU (Frank Allan (Network Mgr))
        cdr@kpc.com (Carl Rigney)
        mwp.michael <MWP.MICHAEL@MELPN1.Prime.COM>

"Peter D. Bille" <PETER@andataco.andataco.com>:
------------------------------------------------
Have not seen this drive yet, but I would think you should get more
than 2gb of formatted capacity, I would guess about 3gb maybe more.
Usually lose about 15% during format.

There is one thing you must consider, the limit for a single
partition/file size under unix is 2gb, you will have to split the
drive up during partition.

Also have not seen the 1.6gb drive yet.

Christian Lawrence <cal@soac.bellcore.com>:
-------------------------------------------
SOS will only support a 2GB partition so you'll have to use several
partitions to get the whole thing .... hopefully hitachi has already
formatted it ?? otherwise not sure what format will do.....

Dave Mitchell <D.Mitchell@dcs.sheffield.ac.uk>:
-----------------------------------------------
Dont talk to me about DK516's! We've got 8 of them, and they've been
no end of trouble. The main problem was that we were supplied with an out-of-revfirmware revision, which caused occasional SCSI bus resets on Suns.
[ This used to occur mainly when the tape drive was used, and caused the tape
to rewind in mid-dump! ]

We had a lot of hassle with Hitachi UK to get them upgraded.

If you do buy one, make sure its NOT rev NO25 !

obs!emike@uu2.psi.com (E. Mike Durbin):
---------------------------------------
We've been using the DK516 for almost two years. No problems.

I've got a bunch of second hand DK314C-41's and DK51x (669 Meg) that also work
well.

I have a 2.1 Gig that formats to 1.742 Gig after 'newfs'.

Kenton C. Phillips <kenton@space.mit.edu>:
------------------------------------------
We are evaluating one on a sparc 10 model 20. It formats to 5606496 sectors
(3296 cylinders, 21 heads, 81 sectors/track), or about 2.8GB. At the moment
I have it partitioned as three 900MB filesystems, which results in about
825MB of available disk space on each (depending on what kind of options
you give to newfs).

Maximum size for a filesystem is 2GB. We haven't decided whether we'll
want three equal size partitions or one large and one small. (Ah, for the
days when 500MB wasn't considered "small".)

The only benchmark we've run is iozone, but with that we got 2.5MB/sec
sustained throughput on sequential writes to the disk, and 3.5MB/sec
on reads. Substantially the fastest SCSI disk we've seen. We're hoping
to try a Seagate 3.6GB drive soon.

michael@ts.go.dlr.de (Michael Klein):
-------------------------------------
The Sunhotline says:

SunOS 4.1.x recognizes not more then 2 GB of DiskSpace,
they advised to move to Solaris > 2.0, there this bug
is fixed.

ups!upstage!glenn@fourx.Aus.Sun.COM (Glenn Satchell - Uniq Professional Services):
----------------------------------------------------------------------------------
I don't actually have one of these disks. Under SunOS the largest
single partition you can have is 2 Gb, so you'd need to divide this
disk into at least two partitions. The Online DiskSuite product from Sun
allows you to have larger partitions (up to something like 2
terrabytes) so that would allow you to make one single large partition
out of it.

celita@taux01.nsc.com:
----------------------
I've purchased 3 of the 3.7 GB disks and installed 2.
They are working fine (about 6 weeks) and the net disk space you are left with
after format is ~ 2.8GB.
Ofcourse you can not have a SINGLE filesystem larger than 2GB on SunOS
unless you use the DISKSUITE product.

fallan@baobab.awadi.com.AU (Frank Allan (Network Mgr)):
-------------------------------------------------------
the DK517 formats out to about 2.7 Gb using the following format.dat entries:

#
disk_type = "Hitachi DK517C-37 2.8G" \
        : ctlr = SCSI : fmt_time = 4 \
        : ncyl = 3256 : acyl = 2 : pcyl = 3258 : nhead = 21 : nsect = 82 \
        : rpm = 5400 : bpt = 44823
 
#
partition = "Hitachi DK517C-37 2.8G" \
        : disk = "Hitachi DK517C-37 2.8G" : ctlr = SCSI \
        : b = 0, 706020 : c = 0, 5606832 : d = 410, 430500 \
        : f = 660, 378840 : g = 880, 1894200 : h = 1980, 2197272

I have included two samples formats to show you relative filesystem sizes.
Partition d in the second example is the largest you can get with SunOS 4.1.3.
These same numbers work with Solaris 2.0 (I haven't tried them with 2.1) as longas you change the partitions from a, b, c etc to 0, 1, 2 etc.
I originally formatted one drive under Solaris 2.0 and it worked quite happily
wihout another newfs under SunOS 4.1.3.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

EXAMPLE 1 - default partition sizes as defined above

Current partition table (original sd0):
        partition a - starting cyl 0, # blocks 0 (0/0/0)
        partition b - starting cyl 0, # blocks 706020 (410/0/0)
        partition c - starting cyl 0, # blocks 5606832 (3256/0/0)
        partition d - starting cyl 410, # blocks 430500 (250/0/0)
        partition e - starting cyl 0, # blocks 0 (0/0/0)
        partition f - starting cyl 660, # blocks 275520 (160/0/0)
        partition g - starting cyl 820, # blocks 2169720 (1260/0/0)
        partition h - starting cyl 2080, # blocks 2025072 (1176/0/0)
 
Filesystem kbytes used avail capacity Mounted on
/dev/sd0b 331569 275558 22855 92% /AnswerBook
/dev/sd0d 202049 163961 17884 90% /export/swap
/dev/sd0f 129503 92506 24047 79% /export
/dev/sd0g 1019746 897801 19971 98% /export1/swap
/dev/sd0h 951542 9 856379 0% /mnt

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

EXAMPLE 2 - partition d is maximum size

Current partition table (original sd0):
        partition a - starting cyl 0, # blocks 34440 (20/0/0)
        partition b - starting cyl 20, # blocks 137760 (80/0/0)
        partition c - starting cyl 0, # blocks 5606832 (3256/0/0)
        partition d - starting cyl 100, # blocks 4193070 (2435/0/0)
        partition e - starting cyl 2535, # blocks 955710 (555/0/0)
        partition f - starting cyl 0, # blocks 0 (0/0/0)
        partition g - starting cyl 3090, # blocks 285852 (166/0/0)
        partition h - starting cyl 0, # blocks 0 (0/0/0)
 
Filesystem kbytes used avail capacity Mounted on
/dev/sd0a 15555 5570 8430 40% /
/dev/sd0d 1970444 1666813 106587 94% /home/mulga
/dev/sd0e 448998 9 404090 0% /mnt
/dev/sd0g 133845 81630 38831 68% /usr
        (partition b is used for swap - 64 Mb)

We have two DK517s and once we worked out the format entries (Hitachi were
not much help :-) ) they worked just fine.

We have a number of 516s and we just use the SUN 1.3 entry for these and have had
no problems for many months.

You may get a negative number for the c partition when you first format the drive,
but ignore it and carry on. Once the drive is formatted and partitioned it seems
happy to give the correct positive numbers and all works well. I have been using
one as the boot disk for a very busy Sparc2 server and the other has export rootand swap for about 30 clients on another server and we have had no problems.

cdr@kpc.com (Carl Rigney):
--------------------------
(Wouldn't this question be more proper for comp.sys.sun.hardware than
sun-managers? It's not really time-critical, is it?)

In article <9302190908.AA07113@mundo.eco.utexas.edu.eco.utexas.edu> you write:
>Does anyone have any experience with Hitachi's 3.7Gb drive under SunOS
>4.1.3? Does it really format out to about 2Gb, or would I actually
>have to partition out a sliver of disk space?

I've been running an eval Hitachi 3.7GB for a few months on a SS2 running
SunOS 4.1.3 with no problems. It comes out to about 2.6GB, so I have
a 2GB partition and a 600MB partition.

Filesystem kbytes used avail capacity Mounted on
/dev/sd3g 2030479 655505 1273451 34% /u/restore
/dev/sd3h 727027 174612 530605 25% /u/local

>For that matter, I'd be interested in hearing any reports on Hitachi's
>1.65Gb DK516.

They work great with the NO28 or QP28 ROMs on a SS2 with SunOS 4.1.1 (with
>1GB patch) or SunOS 4.1.[23], we've been running dozens of them for over
a year with no problems. The NO24 ROM is unusable, though.
We get about 1.2GB of user space from them.

mwp.michael <MWP.MICHAEL@MELPN1.Prime.COM>:
--------------------------------------------
Not sure about the 3.7Gb, but we had some problems with the 1.6Gb.
Basically the ROM was under-rev. The problem was caused by our supplier,
and Hitachi actually read my note on the net and the local service
manager called me and helped out.

Also a problem, our customer did not have the >1.3 Gb patch installed,
so we had a few crashes until that was done. After that, it was plain sailing
and the disks have been brilliant (it's about 9 months since we installed).>

Craig Bevins <craigb@ips.oz.au>:
--------------------------------
        For that matter, I'd be interested in hearing any reports on Hitachi's
        1.65Gb DK516.

I have several of these - great. What more can I say?



This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:07:38 CDT