Date: Fri, 12 Mar 1999 08:45:28 -0800 (PST) From: Matthew Jacob <mjacob@feral.com> To: Christian Weisgerber <naddy@mips.rhein-neckar.de> Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Wangtek 51000HT tape drive Message-ID: <Pine.LNX.4.04.9903120840360.216-100000@feral-gw> In-Reply-To: <7carem$sn1$1@mips.rhein-neckar.de>
next in thread | previous in thread | raw e-mail | index | archive | help
> Matthew Jacob <mjacob@feral.com> wrote: > > > Did you run a CAMDEBUG kernel? That should then print out: > > I have now. Yes, the quirk matches. > > > fctblab.nas.nasa.gov > cpio -iF $TAPE > > 4070 blocks > > fctblab.nas.nasa.gov > mt stat > ... > > File Number: 0 Record Number: 4070 > > fctblab.nas.nasa.gov > mt fsf > > fctblab.nas.nasa.gov > mt stat > ... > > File Number: 1 Record Number: 0 > > fctblab.nas.nasa.gov > cpio -iF $TAPE > > 67 blocks > > Yes, exactly. You shouldn't need to do an explicit fsf, should you? Unless you are explicitly using either a AT&T style tape behaviour or have an application that keeps reading until it gets an error or gets an indication that less data was moved than asked for, yes. Or...[see below] > > > > In real life, of course, I use something like buffer(1) or team(1). So > > And where are these entities? Ports collection? > > team is a port, buffer will be (again) as soon as somebody gets around > to committing ports/10549. > > > Did it used to work that CPIO and/or tar would always end up in the next > > tape file? > > I think so. I believe, in fact, that AT&T invented the 'space to next file on close' behaviour *because* CPIO doesn't do this. > Actually, now that you're asking, I think it rather was like this: > > $ tar x > ... # extracts first archive > $ tar x # does nothing, apparently gets EOF > $ tar x > ... # extracts second archive That counts as part of the description above. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.04.9903120840360.216-100000>