From: terry@phoenix.ocf.llnl.gov (Terry Heidelberg x24154)
Newsgroups: comp.unix.aix
Subject: /etc/backup "lseek" errs on mounted FS.
Date: 7 Apr 92 17:10:32 GMT
Article-I.D.: lll-wink.121942
Organization: Lawrence Livermore National Laboratory

Situation: AIX 3.1.5 on 14 RS/6000 550s with all user filesystems 
cross-mounted with NFS to allow access to any node's files from 
any node.   We have read the disclaimer put out by /etc/backup:

dump: 0511-251 The file system is still mounted; data may not be consistent.
        Use the umount command to unmount the file system; then do the dump.

But we have 24-hour service, jobs run for days, weeks even, so we can't 
afford to take filesystems down (unmount them) for backups (does ANYBODY 
do that?).

We have problems with /etc/backup incremental dumps failing roughly 1 in 5
times with the following type of error behavior (taken from the log of
a test-backup script we began to run, after encountering this problem):

=>rsh ocfkms2 /etc/backup -d 43200 -f /dev/null /u2
    (the "-d 43200" option is bogus for AIX and is apparently ignored
     without comment by backup)
=>The date of this level 9 dump is Thu Mar 26 01:46:59 1992.
=>The date of the last level 0 dump is the epoch.
=>Dumping /dev/ru2 (/u2) to /dev/null.
=>dump: 0511-251 The file system is still mounted; data may not be consistent.
=>        Use the umount command to unmount the file system; then do the dump.
=>Dump is mapping regular files. This is Pass 1.
=>Dump is mapping directories. This is Pass 2.
=>There are an estimated 790637 tape blocks.
=>Dump is dumping directories. This is Pass 3.
=>Dump is dumping regular files. This is Pass 4.
=>2.48% of the dump is done. It should be finished in 196:51.
=>  ... lots of this ...
=>40.74% of the dump is done. It should be finished in 116:34.
=>Cannot read /dev/ru2 [block -1817308824]: count=4096, got=-1
=>The lseek call failed.
=>Cannot read /dev/ru2 [block -231739562]: count=1024, got=-1
=>The lseek call failed.
=>Cannot read /dev/ru2 [block 1969166768]: count=4096, got=-1
=>The lseek call failed.
=>Cannot read /dev/ru2 [block -128777728]: count=4096, got=-1
=>Cannot read /dev/ru2 [block -1750065296]: count=4096, got=-1
=>The lseek call failed.
=>---------------lots more of the above --------------
=>Cannot read /dev/ru2 [block 1456796928]: count=4096, got=-1
=>Cannot read /dev/ru2 [block 951635216]: count=3072, got=-1
=>Cannot read /dev/ru2 [block 951635222]: count=1024, got=-1
=>dump: 0511-250 There are more than 32 block read errors from 537142448.
=>There is an error from which the system cannot recover.
=>dump: 0511-215 The fopen call on /dev/tty failed.
=>The lseek call failed.
=>The lseek call failed.
=>----------------lots more ---------------
=>Cannot read /dev/ru2 [block -2010293516]: count=1024, got=-1
=>Cannot read /dev/ru2 [block -2010293514]: count=1024, got=-1
=>dump: 0511-212 Cannot read the command pipe.:
=>               The specified device does not exist.
=>The dump command has ended abnormally.
=>

The same inconsistency hazard exists on our other Unix systems 
(Sun, DEC, etc.) and WE HAVE NEVER SEEN SUCH PROBLEMS on these other 
systems after years of using the same approach.   It could be 
that there is trash on the dump tape, and we have a false sense 
of security, but at least the dumps seem to finish and on the few 
occasions when we have to do a file restore, we find the file(s) on 
the tape as expected.   (I am aware of the fact that Sun has 
recently published articles (at Usenix LISA) on special system calls, 
FS locks, etc. they added to SunOS to make backups of mounted 
filesystems more reliable.)

We believe that none of our AIX file systems have corruption that would 
explain the failures (however, if you run fsck on a MOUNTED filesystem, 
it appears that lots of FALSE corruption errors are generated).     
We have tried some simulations on an idle system, repeatedly running fsck 
and backup on a mounted, then unmounted, filesystem, with another process
randomly creating and removing files, but can't generate any failures 
this way.   

WE WANT RELIABLE INCREMENTAL BACKUPS ON OUR MOUNTED FILESYSTEMS!

MY QUESTIONS:  
	has anyone else seen this particular problem?   
	Does anyone run incremental backups this way, and never see 
		this problem?    
	Does anyone know what is happening to cause the error?   
	Are there better ways to do incremental backups using /etc/backup?   
	Are there better ways using other tools, e.g. cpio?   

I would greatly appreciate any assistance that anyone can offer on this.
Thanks,
Terry
Newsgroups: comp.unix.aix