Hi Sun Managers,
Thanks to the following for offering solutions:
Niall O Broin
Wally Winzer Jr.
J. Bern
Jim Harmon
David Evans
Derek Mallard
My original question was about why a ufsdump/ufsrestore procedure
had gone bad, and how it problem may be avoided in future.
The complete original question follows the summary.
The responses in regard to the "corrupt" backup tapes tended to
indicate that the most likely cause was a badly repaired filesystem
in the first place, where somehow the contents of a man page seemed
to have become a file name.
The most useful suggestion for making sure the backup tapes are valid
came from j. Bern:
> FWIW, the most popular Method to verify a Tape Backup is to restore
> the last File that got dumped onto Tape to some Place and diff it to
> the Original. (Sorry, don't have all the Options handy.) The (ufs)dump
> 'v' Option, however, is basically nonfunctional ... :-C
Wish I'd thought of that.....
Wally Winzer Jr. suggested the following patches:
> I--------------------------------------
> Patch-ID# 102680-04
> Keywords: dump ufsdump rwall wall utmp security multiple volume tapes
> Synopsis: SunOS 5.4: fixes for ufsdump and wall
> Date: Aug/27/96
>
> II ------------------------------------
> Patch-ID# 103263-02
> Keywords: security ufsrestore y2000 non-unique file dump ufsdump rwall
> wall
> Synopsis: SunOS 5.4: ufsdump, ufsrestore and wall patch
> Date: Aug/29/97
I was upgrading to Solaris 2.5 at the time of the problem, so I am
unable to say whether these patches for 2.4 would be of any use
for the problem I encountered.
Thanks again to all who offerred assistance.
Brian Desmond
Original problem:
------------------------------------------------------------------
Hi Sun Mangers,
I've just recently had a nasty scare when restoring from a backup.
Before repartitioning the system disk, I made a four level 0 ufsdumps of
all partitions onto four different tapes. After repartitioning, and
newfs'ing and fsck'ing the new filesystems I began ufsrestor'ing them.
All went well except for the /usr partition - all seemed well for quite
some time until the error (included below) happened. It would seem that
not all was well with what had been written to tape.
The same error occurred on 2 of the 3 other tapes. I knew not to
trust the third tape as I had read back tables of contents for all
filesystems dumped to tape - and I was aware that in one instance the
table of contents for /usr was shorter than on the other 3 tapes.
Otherwise,
everything seemed OK. All backups were done in single user mode with
nothing else happening on the system.
There were no errors that I saw when making the backups, the new
filesystems, or fsck'ing the new filesystems and so to my mind the failure
happened without warning. I had not noticed any record of filesystem
problems from the fsck which occurs during boot.
As far I was concerned, I had taken reasonable precautions against
such a failure, but this time I got caught out. Fortunately, the upgrade
I was performing didn't worry about missing stuff from /usr, so I got away
with it this time. If anyone has any ideas about what might have happened,
and how I could have avoided the problem, I would appreciate hearing
from you.
The system was a Sparc10, running Solaris 2.4. The patches were not up
to date - I didn't bother checking how far out of date as I was in the
process of upgrading it. The tape drive is an Exabyte 8505c.
With thanks,
Brian Desmond
# ufsrestore -rf /dev/rmt/0cn
symbolic link name: ./share/man/man9f/kstat_create.9f->'\"macro stdmacro
.nr X
.TH kstat_create 9F "4 Apr 1994"
.SH NAME
kstat_create \- create and initialize a new kstat
.SH SYNOPSIS
.LP
.nf
.ft 3
#include <sys/types.h>
#include <sys/kstat.h>
.ft 1
.fi
.LP
.BI "kstat_t *kstat_create(char *" module ", int " instance ,
.if n .ti +5n
.BI "char *" name ", char *" class " ,
.BI "uchar_t " type ,
.if t .ti +5n
.BI "ulong_t " ndata ,
.if n .ti +5n
.BI "uchar_t " ks_flag );
.fi
.SH "INTERFACE LEVEL"
.LP
Solaris DDI specific (Solaris DDI)
.SH ARGUMENTS
.TP 10
.I "module"
The name of the provider's module (such as "sd", "esp", ...).
The "core" kernel
.RB ( /kernel/unix )
uses the name "unix".
.TP
.I "instance"
The provider's instance number, as from
.BR ddi_get_instance (9F).
Modules which don't have a meaningful instance number should use
.BR 0 .
.TP
.I "name"
A pointer to a string that uniquely identifies this
structure. Only
.B \s-1KSTAT_STRLEN\s0 - 1
characters are significant.
.TP
.I "class"
The general class that this kstat belongs to. The following classes
are currently in use:
.BR "disk" ,
.BR "tape" ,
.BR "net" ,
.BR "controller" ,
.BR "vm" ,
.BR "kvm" ,
.BR "hat" ,
.BR "streams" ,
.BR "kstat" ", and"
.BR "misc" .
.TP
.I "type"
The type of kstat to allocate. Valid types are:
.RS 10
.TP 25
.SB "KSTAT_TYPE_NAMED"
named - allows more than one data record per kstat
.TP
.SB "KSTAT_TYPE_INTR"
interrupt - only one data record per kstat
.TP
.SB "KSTAT_TYPE_IO"
I/O - only one data record per kstat
.RE
.TP
.I "ndata"
The number of type-specific data records to allocate.
.TP
.I "flag"
A bit-field of various flags for this kstat.
.B "flag"
is some combination of:
.RS 10
.TP 25
.SB "KSTAT_FLAG_VIRTUAL"
Tells
.B kstat_create(\|)
not to allocate memory for the kstat data section; instead, the driver
will
set the
.B ks_data
field to point to the data it wishes to export. This provides a
convenient
way to export existing data structures.
.TP
.SB "KSTAT_FLAG_WRITABLE"
Makes the kstat's data section writable by root.
.TP
.SB "KSTAT_FLAG_PERSISTENT"
Indicates that this kstat is to be persistent over time. For persistent
kstats,
.BR kstat_delete (9F)
simply marks the kstat as dormant; a subsequent
.B kstat_create(\|)
reactivates the kstat. This feature is provided so that statistics
are not lost across driver close/open (such as raw disk I/O on a disk
with no mounted partitions.)
.sp 1n
.BR Note :
Persistent kstats cannot be virtual,
since ks_data points to garbage as soon as the driver goes away.
.RE
.SH DESCRIPTION
.IX "kstat_create" "" "\fLkstat_create\fP \(em create and initialize a
new kstat"
.IX "create and initialize a new kstat" "" "create and initialize a new
kstat \(em \fLkstat_create\fP"
.LP
.B kstat_create(\|)
is used in conjunction with
.BR kstat_install (9F)
to allocate and initialize a
.BR kstat (9S)
structure. The method is generally as follows:
.sp 1n
.nf
\f3kstat_t *\f2ksp\f3;
.sp 1n
\f2ksp \f3= kstat_create(\f2module\f3, \f2instance\f3,
\f2name\f3, \f2class\f3, \f2type\f3, \f2ndata\f3, \f2flags\f3);
\f3if (\f2ksp\f3) {\f1
\f3/* ... provider initialization, if necessary */\f1
\f3kstat_install(\f2ksp\f3);
\f3}\f1
.fi
.LP
.B kstat_create(\|)
allocates and performs necessary system initialization of a
.BR kstat (9S)
structure.
.B kstat_create(\|)
allocates memory for the entire kstat (header plus data), initializes
all header fields, initializes the data section to all zeroes, assigns
a unique kstat ID (KID), and puts the kstat onto the system's kstat
chain.
The returned kstat is marked invalid because the provider (caller) has
not yet had a chance to initialize the data section.
.LP
After a successful call to
.B kstat_create(\|)
the driver must perform any necessary initialization of the data section
(such as setting the name fields in a kstat of type
.SB KSTAT_TYPE_NAMED
).
Virtual kstats must have the
.B ks_data
field set at this time.
The provider may also set the
.BR ks_update ", " ks_private ", and " ks_lock
fields if necessary.
.LP
Once the kstat is completely initialized,
.BR kstat_install (9F)
is used to make the kstat accessible to the outside world.
.SH "RETURN VALUES"
If successful,
.B kstat_create(\|)
returns a pointer to the allocated kstat.
.SB "NULL"
is returned on failure.
.SH "CONTEXT"
.LP
.BR kstat_create(\|)
can be called from user or kernel context.
.SH SEE ALSO
.BR kstat (3K),
.BR kstat_delete (9F),
.BR kstat_install (9F),
.BR kstat_named_init (9F),
.BR kstat (9S),
.BR kstat_named (9S)
.LP
.TZ DRIVER
; too long 4470
#
-- Brian Desmond Department of Psychology University of Melbourne Parkville, Victoria 3052 AustraliaEmail: brian@psych.unimelb.edu.au Phone: +61 3 9344 4208 Fax: +61 3 9347 6618
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:12:31 CDT