Date: Sat, 13 Sep 1997 23:42:18 -0400 From: "Louis A. Mamakos" <louie@TransSys.COM> To: current@freebsd.org Subject: restore seems to be misbehaving Message-ID: <199709140342.XAA07327@whizzo.TransSys.COM>
next in thread | raw e-mail | index | archive | help
I just noticed restore(1) acting strangely on me. I don't know when it
starting doing this exactly, as I don't normally restore files from my
DAT tape with any regularity.
When I run 'restore -t', I get a bunch of 'resync restore' errors. What's
strange is that when I run 'dd if=/dev/rst0 bs=20b | restore -t -f -'
instead, everythings works just fine.
What really puzzles me is that when I ktrace the first case, I notice
that the read(2) syscall is returning 32K bytes, rather than the 10K bytes
that I expected:
root@whizzo[136] # ktrace -t cnsu restore t
Dump date: Sat Sep 13 10:15:07 1997
Dumped from: the epoch
Level 0 dump of / on whizzo.TransSys.COM:/dev/sd0a
Label: none
resync restore, skipped 22 blocks
resync restore, skipped 22 blocks
resync restore, skipped 22 blocks
resync restore, skipped 22 blocks
resync restore, skipped 22 blocks
resync restore, skipped 22 blocks
resync restore, skipped 22 blocks
resync restore, skipped 22 blocks
resync restore, skipped 22 blocks
2 .
7680 ./usr
7943 ./cdrom
7946 ./dos
7762 ./tmp
7944 ./crypt
7945 ./devfs
[....]
and then doing the kdump:
7160 restore CALL open(0x78050,0,0)
7160 restore NAMI "/dev/rst0"
7160 restore RET open 6
7160 restore CALL read(0x6,0x89000,0x8000)
7160 restore RET read 32768/0x8000
subsequent reads of FD 6 also return 32768 bytes; the trailing garbage
in the buffer are likely the cause of the 'resync restore' errors.
What I don't get is why dd(1) doesn't have this problem. From a ktrace/kdump:
7191 dd CALL open(0xefbfdb7a,0,0)
7191 dd NAMI "/dev/rst0"
7191 dd RET open 6
7191 dd CALL fstat(0x6,0xefbfd9d8)
7191 dd RET fstat 0
7191 dd CALL ioctl(0x6,0x40406d02 ,0xefbfda38)
7191 dd RET ioctl 0
[...]
7191 dd CALL read(0x6,0x15000,0x8000)
7191 dd RET read 10240/0x2800
7191 dd CALL write(0x7,0x15000,0x2800)
7191 dd RET write 10240/0x2800
7191 dd CALL read(0x6,0x15000,0x8000)
7191 dd RET read 10240/0x2800
7191 dd CALL write(0x7,0x15000,0x2800)
7191 dd RET write 10240/0x2800
I dunno where to look next. Two programs, seemingly doing the same
thing, are getting different results on the exact same tape.
I'm running a fairly recent 3.0-current version, and am using a DDS-2
tape-changer driver which seems to be working OK..
FreeBSD 3.0-CURRENT #0: Sat Sep 6 14:52:56 EDT 1997
louie@whizzo.TransSys.COM:/usr/src/sys/compile/WHIZZO
CPU: Pentium (132.62-MHz 586-class CPU)
Origin = "GenuineIntel" Id = 0x52b Stepping=11
Features=0x1bf<FPU,VME,DE,PSE,TSC,MSR,MCE,CX8>
real memory = 67108864 (65536K bytes)
ncr0: <ncr 53c825 fast10 wide scsi> rev 0x02 int a irq 15 on pci0.20.0
ncr0: minsync=25, maxsync=206, maxoffs=8, 16 dwords burst, normal dma fifo
ncr0: single-ended, open drain IRQ driver
st0 at scbus0 target 2 lun 0
st0: <ARCHIVE Python 28849-XXX 4.CM> type 1 removable SCSI 2
st0: Sequential-Access
st0: NCR quirks=0x2
st0: 5.0 MB/s (200 ns, offset 8)
density code 0x13, 512-byte blocks, write-enabled
louie
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709140342.XAA07327>