Thanx again for the responses. A number of you asked for a summary which is
enclosed, and I've tried to include pertinent responses below. My apologies
if I left someone out.
In summary, lots of people are using Wren VII's without any difficulty, and
it turns out that I'm below the "2^21 Sectors limit for older SCSI drivers"
so it's not a problem for me. However, I did NOT get an authoritative
response about what the filesystem size limit actually is for SunOS4.1.1
As an aside about filesystems, I'm aware that the default number of inodes
allocated in SunOS4.1.1 is a bit high for "normal" file systems. For example,
my News partition is 35% full for space, but only 17% full for inodes, and
News is probably one of the most "inode intensive" uses of disks. However,
one respondee mentioned the ever-present 10% min-free. All I have ever found
about this is that not using this can cause up to a three-fold decrease in disk
performance. But I hate to "waste" ~100 Mbytes. Appreciate any authoritive
E-mail on this subject.
As a final aside, I got a number of comments in regards to my posting
about booting a machine diskless (rather than via tapes) to recover from
clobbering libc.so. Yes, of course one needs another Sparc! :-)
But given that, the additional software does NOT take up much space, since
you are "sharing" /usr. What I do here is just keep /etc/ethers up to date,
some open disk space (~5 for root, and 16 for swap), and rarpd running. Then
it's simply a matter of add_client on the server, and then boot net (b le()).
and away I go - whole process taking ~5 minutes. You've now got a machine
running full SunOS, with access to all the tools/utilities/etc.
I agree the CD-ROM is a whole lotter better than 1/4", but several people
agreed that if you can do the diskless boot route, it's the way to go,
especially if you need to recover files from / or /usr (which ideally
one should not have to do).
P.S. rarpd & exportfs may need to be bumped/updated correctly.
Sorry to ramble on (I guess I'm not helping the S/N ratio, but I think most of
the above is of general interest) - Here's the original post and the responses:
Mr/s Sun Managers,
I've seen the subject of disk partitions > 1 GByte discussed as being dangerous.
Older 31 bit SCSI implementations did a mod 2^30, which caused some undesireable
things to happen when addressing near the end of the disk.
I'm sorry that have forgotten how it turned out. Now I need to know! :-)
We recently took delivery of a Wren VII and installed it on a Sparc 2
running SunOS4.1.1 with no patches. Here's some output:
dmesg sd1 at esp0 target 1 lun 0
sd1: <ADT/Wren VII 94601-1200 cyl 1929 alt 2 hd 15 sec 69>
sd2 at esp0 target 2 lun 0
sd2: <Seagate WrenVII cyl 1956 alt 2 hd 15 sec 69>
dkinfo sd2: Emulex MD21 controller at addr f8800000, unit # 16
1956 cylinders 15 heads 69 sectors/track
a: 2024460 sectors (1956 cyls)
starting cylinder 0
c: 2024460 sectors (1956 cyls)
starting cylinder 0
df /dev/sd2a 950220 456226 398972 53% /notavailableYET
* First, why do two Wren VII's have a different number of cylinders?
* Second, my partion is > 1GByte, but < 1GByte usable. Is this of concern?
And what is the current limit for disk partitions? I've seen this bounced
around in too many newsgroups to recall which numbers go with which W/S's.
Thanx in advance (and I will, of course, summerize if interest),
Alek Komarnitsky 303-449-0649
Software Tools Manager, Spatial Technology, Inc. 2425 55th Street, Bldg A
alek@spatial.com Boulder, CO 80301-5704
P.S. I assume the workaround is to just use format to make the partition size
less than the max and go from there. Any comments on limits on other
systems are also mucho appreciated (understand that Ultrix < 4.1 is a gotcha)
[comments from canuck@rice.edu (Mike Pearlman)]
We have a lot of Wren VIIs here on our Suns and they work. If you have
SPARCSTATION2s you need a patch from Sun to boot off the Wrens but if you do not
boot off them then there is no problem. However, do not use "format" to reformat
or repair the disks without checking something first. The people at Sun, can only handle < 128 defects per disk. It turns out that on a disk the size of the
Wren VII 200-300 defects is totally ok. I have purchased software that provides
me with a format that will work ok with the Suns and automatically computes
the correct disk geometry. (Cost: ~$100-$200).
[I can confirm that booting from Wren 7's doesn't work - I get "error in disk
label" or somthing like that (so I just keep root & swap on the 200 Meg drive).
I did NOT seem to run into the problem with # of defects. Format finds 129
in one of the new ones', and 150 in an existing one. I suspect Mike may have
referred to a pre-SunOS4.1.1 limit]
Now to the different sizes. Your disks came pre-formatted and were probably formated by two different companies or programs. The Wrens use a method
called zone recording which in basic terms means that number of sectors per
track is not constant. Unfortunately, the unix software is designed expect
a constant number of sectors per track. The disk does not care since all a SCSI
disk sees is a block number which is what the Sun driver gives it. The only fixed parameters on the Wren are the maximum number of blocks and the number of
heads. The trick is to come up with a number of cylinders and sectors per
track so that the total cylinders*heads*sectors_per_track is as close to
the maximum capacity as possible. There are additional tradeoffs involved, one
of the things that formatting a disk does is it allocates spare sectors to handle existing and "future" bad blocks. The Wren can do this in two ways,
1) allocate a few sectors per cylinder
2) 1 sector per track
Thus your choice of geometry is determines how many sectors are reserved for
spare cylinders.
Hope this helps
[Comments from matt@oddjob.uchicago.edu (Matt Crawford)]
> Older 31 bit SCSI implementations did a mod 2^30, which caused some ...
21 21
[Ack! continue this thread Matt - WHO is using older versions of SCSI]
My solution (until better driver is available) tell newfs to build a
filesystem of only 2^21 sectors. Same dodge works on Ultrix, too.
[comments from stefan@centaur.astro.utoronto.ca (Stefan Mochnacki)]
> * First, why do two Wren VII's have a different number of cylinders?
My experience is that different batches of the same Wren model have
different numbers of available blocks. Did you buy these from different
suppliers/dealers ? [Yep]
> * Second, my partion is > 1GByte, but < 1GByte usable. Is this of concern?
Taking your bigger case, I see 1,036,523,520 bytes. 1 GB is 1,073,741,824
bytes.
The usable space is reduced due to : (1) the space for inodes taken
when you run newfs (about 6% max), and (2) the spare room needed
by the BSD file system (default 10%, can be changed when you run newfs).
[1 - yep, and I understand quite a few inodes - the number of which can be
reduced for "normal" (non-News, etc.) type file systems. 2 - Per comment
above, does anyone really (!) know how big a penalty <10% causes?]
I formatted a Wren VII with: ncyl=1925, nheads=15, nsect=70, giving
1,034,880,000 bytes, so I guess you squeezed about 1.6 MB more out of it.
Also, I believe using an odd number for nsect produces fewer inodes by
default, so you usable space will be a few MB more. However, you won't be
able to have as many files. Depends on your applications: lots of little files,
or fewer but bigger files.
> And what is the current limit for disk partitions? I've seen this bounced
> around in too many newsgroups to recall which numbers go with which W/S's.
I believe it defaults to 1 GB max., but I'm sure you'll get more expert
answers to that.
[I didn't actually]
[comments from dan@breeze.bellcore.com (Daniel Strick)]
1) 1 GB = 2^30 bytes = 2^21 sectors = 2097152 sectors > 2024460 sectors
(so you don't have a problem)
[So 2^21 sectors IS the limit?]
2) The geometry of a Wren-VII is somewhat programmable. The "default"
geometry produces 2026965 sectors. 2026965 / (15*69) = 1958 + change.
After reserving 2 cylinders (the traditional number) for spares,
you have 1956 left. If you don't use the default/traditional
parameters, other capacities are possible.
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:15 CDT