From owner-freebsd-current Sat Sep 13 20:42:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA17777 for current-outgoing; Sat, 13 Sep 1997 20:42:28 -0700 (PDT) Received: from whizzo.TransSys.COM (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA17771 for ; Sat, 13 Sep 1997 20:42:22 -0700 (PDT) Received: from localhost.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.TransSys.COM (8.8.7/8.7.3) with SMTP id XAA07327 for ; Sat, 13 Sep 1997 23:42:19 -0400 (EDT) Message-Id: <199709140342.XAA07327@whizzo.TransSys.COM> X-Mailer: exmh version 2.0zeta 7/24/97 To: current@freebsd.org From: "Louis A. Mamakos" Subject: restore seems to be misbehaving Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 13 Sep 1997 23:42:18 -0400 Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 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 real memory = 67108864 (65536K bytes) ncr0: 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: 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