On Thursday 07 June 2007 14:31, Tim Kientzle wrote: > sudo ktrace tar -tf /dev/sa0 > > Then run 'kdump | less' and see if you can find a pair of 'lseek' > calls, which will probably look something like this: > > 53127 bsdtar CALL lseek(0x3,0,0,0,0x1) > 53127 bsdtar RET lseek 6656000/0x659000 > 53127 bsdtar CALL lseek(0x3,0,0x70800,0,0x1) > 53127 bsdtar RET lseek 7116800/0x6c9800
I get the following.. 5378 bsdtar CALL lseek(0x3,0,0,0x1) 5378 bsdtar RET lseek 51200/0xc800 5378 bsdtar CALL lseek(0x3,0,0x2f800,0x1) 5378 bsdtar RET lseek 245760/0x3c000 > I believe you'll find that the SCSI tape driver > in 6.2 lies: It does not actually seek, but the > two lseek calls return different values. As a result, > tar believes that the body of the tar entry has been > skipped when it hasn't. This doesn't occur with tar > from 6.1 because the seek optimization was added after > that; it doesn't happen with compressed archives because > you cannot seek in compressed files. Hmm, so I wonder if this hypothesis can be tested by asking for the position of the tape using mt before and after the seek.. Quick kludge attached.. [cain 15:54] ~ >./test /dev/nsa0: logical block location 0 /dev/nsa0: hardware block location 0 Current pos is 0 /dev/nsa0: logical block location 0 /dev/nsa0: hardware block location 0 Current pos is 100 /dev/nsa0: logical block location 0 /dev/nsa0: hardware block location 0 -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
pgpWcBAlxzRiT.pgp
Description: PGP signature
