bb@reef.cis.ufl.edu (Brian Bartholomew) (02/26/91)
The EE department's server machine has two identical disks, one that contains the root file system, and one that contains /users: # uname -a HP-UX kzin 7.0 B 9000/375 kzin # diskinfo /dev/rdsk/0s0 /dev/rdsk/0s0 vendor: HP product id: 2213A type: direct access device size: 663814144 bytes bytes per sector: 512 # diskinfo /dev/rdsk/1s0 /dev/rdsk/1s0 vendor: HP product id: 2213A type: direct access device size: 663814144 bytes bytes per sector: 512 # bdf /users Filesystem kbytes used avail capacity Mounted on /dev/dsk/1s0 623486 211587 349550 38% /users The appropriate section from /etc/disktab: ############################################### # The HP2213A is a SCSI Coyote II # Total formatted capacity: 663 Mbytes # 512 Bytes/sector # 56 sectors/track; 16 heads; 1447 cylinders; # Total: 648256 1k sectors hp2213A|HP_2213A|hp97548S|HP_97548S:\ :64 MBytes swap:ns#28:nt#16:nc#1302:\ :s0#583296:b0#8192:f0#1024:\ :se#512:rm#4002: hp2213A_96MB:\ :96 MBytes swap:ns#28:nt#16:nc#1229:\ :s0#550592:b0#8192:f0#1024:\ :se#512:rm#4002: hp2213A_42MB:\ :42 MBytes swap:ns#28:nt#16:nc#1351:\ :s0#605248:b0#8192:f0#1024:\ :se#512:rm#4002: hp2213A_noswap:\ :noswap:ns#28:nt#16:nc#1447:\ :s0#648256:b0#8192:f0#1024:\ :se#512:rm#4002: The first disk, containing root, works fine. It is exported in toto to the other 7 machines on the network (not my design - don't flame me). The second disk, containing /users, does not work fine. In fact, it works very slowly. An 'll' generally takes about 1/2 second per line for most of the larger (80 entries max) directories on this disk. Furthermore, an fsck (while it is unmounted, of course) sounds much slower than the root disk, in terms of head-shaking. It is exported in toto to the other 7 machines, as well. The second disk was added a few months after the first one. I do not know how it was formatted or mkfs'ed (newfs'ed?) - which is part of the problem. I suspect that a disk's performance may be hurt this badly by an inappropriate filesystem layout and/or tunable perameters. What I would like to see would be: 1. Confirmation that my suspicions are reasonable. 2. Confirmation of an appropriate /etc/disktab entry. 3. Suggestion of some way to read the mkfs parameters back off of both disks for diagnostic purposes. Thanks. -- "Any sufficiently advanced technology is indistinguishable from a rigged demo." ------------------------------------------------------------------------------- Brian Bartholomew UUCP: ...gatech!uflorida!beach.cis.ufl.edu!bb University of Florida Internet: bb@math.ufl.edu
kinsell@hpfcdj.HP.COM (Dave Kinsell) (03/03/91)
>I suspect that a disk's performance may be hurt this badly by an >inappropriate filesystem layout and/or tunable perameters. What I >would like to see would be: > > 1. Confirmation that my suspicions are reasonable. They're reasonable, but the tuning has a bigger impact on sequential throughput than on random activity. The execution of 'ls' would generate little sequential activity, with the exception of the load of 'ls' itself, if needed. My first guess would be an uneven workload on the disks, or some strangeness caused by the networking configuration. > 2. Confirmation of an appropriate /etc/disktab entry. They match what we sent out. > 3. Suggestion of some way to read the mkfs parameters > back off of both disks for diagnostic purposes. > The tuning info is much easier to come by than the block sizes. Tunefs gives you the old and the new values. Look for 4 ms rotdelay and maxcontig of 1 for the best performance with those disks. If they're not right, rebuilding the file systems would be necessary to give you full advantage of the proper tuning. Another thing to look at is the possibility of a marginal disk that might be having trouble reading data. Look in msgbuf via the dmesg command to see if a large number of I/O errors are being reported for the drive. >Thanks. >Brian Bartholomew UUCP: ...gatech!uflorida!beach.cis.ufl.edu!bb >University of Florida Internet: bb@math.ufl.edu David Kinsell paid by, but not representing, Hewlett-Packard