Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 7 Jun 2007 15:55:21 +0930
From:      "Daniel O'Connor" <doconnor@gsoft.com.au>
To:        Tim Kientzle <kientzle@freebsd.org>
Cc:        Robin Gruyters <r.gruyters@yirdis.nl>, freebsd-stable@freebsd.org
Subject:   Re: Unrecognized archive format with RELENG_6_2 and RELENG_6
Message-ID:  <200706071555.22707.doconnor@gsoft.com.au>
In-Reply-To: <46679117.5060909@freebsd.org>
References:  <20070601114047.z6qgi686os4ogw4o@server.yirdis.nl> <20070606095820.83tast6s0804osos@server.yirdis.nl> <46679117.5060909@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart2149425.jFjPhz8vSj
Content-Type: multipart/mixed;
  boundary="Boundary-01=_ST6ZGJeTQapGTpv"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

--Boundary-01=_ST6ZGJeTQapGTpv
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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=20
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

=2D-=20
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

--Boundary-01=_ST6ZGJeTQapGTpv--

--nextPart2149425.jFjPhz8vSj
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (FreeBSD)

iD8DBQBGZ6TS5ZPcIHs/zowRAmN8AJ9gv63hOJeThRAMy83vyYb6ZRrCXgCfaNfu
yNh2BkfDSX2+dipZLlequxA=
=BmN2
-----END PGP SIGNATURE-----

--nextPart2149425.jFjPhz8vSj--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200706071555.22707.doconnor>