In response to my query concerning WORM drives (see bottom for copy of
my question), The basic consensus was that I should check with my
vendor :-(
I have discovered that an ls -R will chew up disk space. I guess
because the access times are being updated. WOW! my FM never said
anything about this.
If anyone wants to know what my vendor has to say (I can tell you it
will probably be of no interest), send me mail. If I discover
new and startling facts, I'll summarize again.
Thanks to all who responded.
=================== individual replies =========================
>From Daniel@europarc.xerox.com Fri Feb 28 09:38:50 1992
Date: Fri, 28 Feb 1992 06:38:11 PST
From: Ian Daniel <Daniel@europarc.xerox.com>
To: mdl@cypress.com (J. Matt Landrum)
Subject: Re: not enough W in WORM
In-Reply-To: <9202280228.AA02152@al.cypress.com>
References: <9202280228.AA02152@al.cypress.com>
I had a guy come in this very morning trying to sell us stuff....as an
afterthought , he mentioned a device which plugs into SCSI and you then
plug a WORM drive into it. The WORM then appears as a disk to the Sun ,
cutting out all the software configs etc....
Do you want details of this?
Ian
>From miker@sbcoc.com Fri Feb 28 11:09:58 1992
Date: Fri, 28 Feb 92 09:37:24 CST
From: Mike Raffety <miker@sbcoc.com>
X-Organization: SBC/OC Services, L.P.
To: mdl@cypress.com
Subject: Re: not enough W in WORM
All of your space consumption problems are internal to the WORM, and
there's nothing to tweak on the Sun (e.g., format.dat) to help. Talk
to the vendor; that overnight shrinking free space on a read-only
drive is especially suspicious.
Please be sure to summarize back to the list; thanks.
>From bb@math.ufl.edu Fri Feb 28 14:05:32 1992
From: bb@math.ufl.edu
To: mdl@cypress.com (J. Matt Landrum)
Subject: Re: not enough W in WORM
In-Reply-To: Your message of Thu, 27 Feb 92 20:28:54 -0600.
<9202280228.AA02152@al.cypress.com>
Date: Fri, 28 Feb 92 14:51:58 EST
I've never used a WORM, but this comment got me thinking:
> This drive works ok if the directory archived is relatively small,
> but here's another thing weird... I had a user complete his archive
> to the WORM. The LCD said that 79 Mb was left (UNIX thought it was
> 150). I came in the next day and the LCD said 40 Mb. I asked him
> if he had written anymore. He had not, but set the R/W switch to
> read only to be safe. Later that afternoon the LCD said 0 was left!
> I believe the file system was mounted read-only as well, but I'm not
> sure.
What happens when update tries to sync the drive every 30 seconds?
[Doing a manual sync has no effect. Maybe I just haven't waited long
enough or done enough of them. However, if I do an ls -R the disk
just gets eaten up as fast as it can go. I guess because the access
times are being updated].
"The reasonable man adapts himself to the world: the unreasonable
one persists in trying to adapt the world to himself. Therefore
all progress depends on the unreasonable man." -- George Bernard Shaw
-------------------------------------------------------------------------------
Brian Bartholomew -- University of Florida Internet: bb@math.ufl.edu
=========================== original query ===========================
>From sun-managers-relay@delta.eecs.nwu.edu Fri Feb 28 01:34:48 1992
Sender: sun-managers-relay@eecs.nwu.edu
Date: Thu, 27 Feb 92 20:28:54 CST
From: mdl@cypress.com (J. Matt Landrum)
To: sun-managers@eecs.nwu.edu
Subject: not enough W in WORM
Cc: bwg@cypress.com, cwl@al.cypress.com, hdm@cypress.com, ks@al.cypress.com,
skb@al.cypress.com, wsl@al.cypress.com
Sunmanagers - HELP!
We purchased a WORM drive in July of 1990. To this day it won't work
like I want or like I think it should. Hopefully there is one of you
that has had a similar experience and/or can answer some questions.
This would be of great help to me. Sun won't help. The company I
bought it from is not much help. I have currently stopped all my
designers from using it and there is some valuable archive data we
need to retrieve. Also, I have wasted countless dollars on media as a
result of unsuccessful archive attempts. I will skip all the problems
that are relatively under control. Forgive the length, but my
problems are extensive...
The drive is a MAXTOR RXT-800S subsystem connected to a SPARCstation
1+ running 4.1.1. It is the last item on the SCSI chain which
includes a hard-drive, tape, and CD-ROM.
There are several options which can be set via a control panel on the
front of the subsystem. I have set the pertinent ones as follows:
SCSI Parity = ON
SCSI RESET = SOFT
CAPACITY = DISK SIZE
ATTENTION OPTION = REMOVAL IGNORED
Problem 1) (the one causing the most grief)
I have heard that the algorithm the optical drive interface uses for
storing files uses an absolute path name for EVERY file written to the
media which creates an overhead of 15-40% depending on the hierarchy.
The company I bought the drive from does not seem to believe this or
be aware of it. This may be the only way they can emulate a r/w feel.
When I am archiving I don't need this functionality. I am seeing big
discrepancies in the space used on my magnetic disk and the space
required on the WORM. I have been given several format.dat entries to
try. I don't know whether the company just keeps re-fining these or
what.
current:
: ncyl = 793 : acyl = 2 : pcyl = 795 : nhead = 15 : nsect = 64 \
: rpm = 3600 : bpt = 39936
...
: a = 0,0 : b = 0,0 : c = 0,761280 : g = 0,0
============================================================================
: ncyl = 793 : acyl = 2 : pcyl = 795 : nhead = 15 : nsect = 64 \
: rpm = 3600 : bpt = 32768
...
: a = 0,0 : b = 0,0 : c = 0,761280 : g = 0,0
============================================================================
: ncyl = 780 : acyl = 2 : pcyl = 782 : nhead = 15 : nsect = 64 \
: rpm = 3600 : bpt = 16384
....
: a = 0,0 : b = 0,0 : c = 0,748800 : g = 0,0
============================================================================
: ncyl = 2280 : acyl = 2 : pcyl = 2282 : nhead = 15 : nsect = 35 \
: rpm = 3600 : bpt = 20833
...
: a = 0,0 : b = 0,0 : c = 0,1197000 : g = 0,0
============================================================================
There are basically 3 size indicators I have: 1) df which gives me one
number, 2) du which will give me identical numbers on the WORM
filesystem and on the recently copied sun filsystem hierarchy, and 3)
an LCD giving available space on the front of the WORM which seems to
have little correlation to anything. When the LCD says 0, I can't
write anymore, even if the Sun thinks there is space left.
I can understand a little discrepancy, but I had a 200 Mb hierarchy
that would not fit on the media when the LCD reported 390 Mb free
before the tar copy (not expanding links obviously). I feel that
either the number of files or the depth of the hierarchy have
something to do with it.
Do I need to play with the mkfs parameters (of newfs) or should the
format.dat parameters handle this?
Here is a sample of when I tried to copy a 290 Mb filesystem to the
WORM filesystem. The column "UNIX says" is what is reported by df;
"WORM says" is the LCD display on the subsystem.
UNIX Says WORM says Unix Delta WORM Delta
===============================================
357 Mb 390 Mb NA NA (but notice it has 47 Mb more)
...
270 Mb 248 87 142 (1.63 Mb, used for every 1
LCD available has passed
UNIX already)
...
269 242 1 6 (6 to 1)
...
268 232 1 10 (10 to 1)
...
260 218 8 14 (1.75, better but still sucks)
you can see this is not looking good
This drive works ok if the directory archived is relatively small, but
here's another thing weird... I had a user complete his archive to
the WORM. The LCD said that 79 Mb was left (UNIX thought it was 150).
I came in the next day and the LCD said 40 Mb. I asked him if he had
written anymore. He had not, but set the R/W switch to read only to
be safe. Later that afternoon the LCD said 0 was left! I believe the
file system was mounted read-only as well, but I'm not sure.
Problem 2)
The drive occasionally locks up even when mounted read-only when large
files are read or copied from the WORM media. The diagnostic from the
manual indicates that the media was written with a compression format
unknown to the optical disk drive interface. This most often happens
when a user is trying to do a tar from the drive to tape (trying to
salvage the info before I give the drive to Letterman to hurl off a
tall building). tar gives an "I/O error or a "No such device or
address" error.
Problem 3)
Occasionaly my sun will crash and not reboot until I turn the WORM
subsystem off. The message here is usually panic: ufs_putpage hole.
I've recently seen a discussion of this on "sunmanagers". Maybe
upgrading to 4.1.2 would help.
Problem 4)
Sometimes when doing large writes my sun sometimes crashes with
"freeing free inode". This never happens when the WORM is not active.
Has anyone had any similar experiences? Should I just chunk it and
get a r/w drive and if so, should I get a Sample-Servo or Continuous
Composite format?
I'd be grateful for any input, even if it is just general info on WORMs.
thanx,
matt
Matt Landrum | mdl@cypress.com
Cypress Southeast Design Center | office: (601) 324-4609
1 Research Blvd, Suite 200 | "There's a fine line between
Starkville, MS 39759 | stupid and clever" -- N. Tufnel
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:37 CDT