Very Computer

Errors when I perform dumps to a tape on remote machine:

  DUMP: short read error from /dev/sdc1: [sector -1537013765]:
count=512, got=0
  DUMP: bread: lseek2 fails!
  DUMP: short read error from /dev/sdc1: [sector -1537013764]:
count=512, got=0
  DUMP: bread: lseek2 fails!
  DUMP: short read error from /dev/sdc1: [sector -1537013763]:
count=512, got=0
  DUMP: bread: lseek2 fails!

the dump script executes:

    /sbin/dump 0dsf 122000 140000 $TAPE $FS

This script is identical to two other machines that I backup remotely as

well (same tapehost, etc).  The script worked fine until a couple of
days ago. not only do I get the errors on sdc1 but also on /dev/md0 (see

fstab).  Interesting to note that backup of /boot works fine (same
physical disks as the md0 set).  There is nothing wrong with the disks -

no controller or disk errors in log files, system reboots cleanly
without fsck, etc.  Disks are all SCSI, OS is RH 7.0 - RH6.2 on machine
with tape drive (HP 4mm DAT).  Strace of dumpscript doesn't show any
obvious clues.

/etc/fstab
/dev/md3                /                       ext2    defaults 1 1
/dev/md0                /boot                   ext2    defaults 1 2
/dev/sdc1               /home                   ext2    defaults 1 2

[...off-topic LINTEL quandry snipped...]

        Moron, post your LINTEL questions to the LINTEL newsgroups.  They are
off-topic on UNIX newsgroups.

                Happy to have cleared things up for you,
                                Don

--
***********************      You a bounty hunter?
* Rev. Don McDonald   *      Man's gotta earn a living.
* Baltimore, MD       *      Dying ain't much of a living, boy.
***********************             "Outlaw Josey Wales"

You are dumping to a filesystem that is active.  One of the files on it got
shorter between the phase of the dump that mapped all of the inodes and their
sizes and the phases that copied that particular file to tape.

As you noted, a filesystem with much less activity will see this error much
less often, and a filesystem like /boot that may as well be read-only will
never get this error.

The more data your filesystem contains, and the more files it contains, and the
more active the files on it are being changed, the more often you will encounter
this error.  Fix by running backups at a lull time, getting faster tapes, doing
some sort of mirror/break-mirror/backup-offline-copy, orr similar.