Date: Fri, 26 Aug 2011 19:43:56 -0500 (CDT) From: Robert Bonomi <bonomi@mail.r-bonomi.com> To: fbsd-ml@gehlbach.com, questions@freebsd.org Subject: Re: Problem reading from tape drive Message-ID: <201108270043.p7R0hul1028575@mail.r-bonomi.com> In-Reply-To: <4E57EAEF.1020300@gehlbach.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> From owner-freebsd-questions@freebsd.org Fri Aug 26 13:51:51 2011
> Date: Fri, 26 Aug 2011 14:50:23 -0400
> From: Renee Gehlbach <fbsd-ml@gehlbach.com>
> To: questions@freebsd.org
> Cc:
> Subject: Re: Problem reading from tape drive
>
> On 08/25/2011 06:38 PM, Robert Bonomi wrote:
> >> From owner-freebsd-questions@freebsd.org Thu Aug 25 13:57:20 2011
> >> Date: Thu, 25 Aug 2011 14:24:57 -0400
> >> From: Renee Gehlbach<fbsd-ml@gehlbach.com>
> >> To: questions@freebsd.org
> >> Cc:
> >> Subject: Problem reading from tape drive
[[ sneck ]]
> >> So, when I tell it to forward space file at the end of each tar file, it
> >> is able to read all four files correctly. This leaves me scratching my
> >> head, and wondering what the heck I've set up wrong. Any ideas?
> > Tape drivers _always_ write two EOFs when the tape device is closed.
> > This ensures there is always a valid 'EOT' on the tape.
> >
> > They're _suppoesed_ to backspace over the 2nd EOF mark, so that
> > a subsequent write has only one EOF between it and the prior file.
> >
> > Looks like your drive isn't doing the 'backspace' right.
> >
> > I suspect the 'easiest' work around is the one you've discovered -- do
> > an 'mt -fsf' after avery tape file 'read'.
> >
> OK, I feel pretty dense.... When you're saying they write two EOFs when
> the device is closed, would this happen every time you write a file?
Authortative answer "it depends". you can 'cat' several files to te
tape device, in one invocation, and there will be no EOF marks between
the source files.
I meant _exactly_ what I said, in describing tape operationss. To wit:
Every time an application calls close(2) (or fclose(3), which calls
close(2)) *or* exits without closing an open file in which case the O/S
invokes close(2) on every open file descrriptor.
> Or
> would it be every time the tape is unmounted? Or would that depend on
> the program you're using?
Nope, it's automatic, and internal to th O/S.
> Is there any way I could test to make sure this is in fact what's happening?
Try writing several files to the tape, each in it's own operation,
and issue a 'mt -bsf' between each operation.
THEN try reading from the tape. with just successive 'read' operations.
*NO* 'mt' positioning
If everything is working 'properly', there will be *ONLY*ONE* file on the tape.
If there is an O/S failure to 'backspace on close' you'll get all the original
files, one on each read attempt.
If the O/S has a _complete_ 'failure to backspace', you'll get a tape that
functions identially to your earlier tests -- you can find all the file
by 'mt -fsf' between reads
Other things to try.
1) *write* a multi-file tape under Unbuntu, and try to read it under FreeBSD.
2) *write* a multi-file tape under FreeBSD, and try to read it under Unbuntu.
3) If there are read issues, see if the 'mt -fsf' hack allows you to
find everything.
> And would the problem with it not doing the backspace right be an issue
> with the FreeBSD tape driver? Or SCSI card driver? Or what driver?
"Yes." <grin>
A prime candiate would be sa(4) . See 'filemark handling' at the end of
the manpage. mtio(4) is another candidate, see para. 3 of that manpage.
And it is _possible_, albeit *unlikely, that somebody screwed up on the
scsi card driver and the code for that particular command is broken.
> Obviously not a problem with the drive itself, since I don't have this
> problem with Ubuntu.
To be precise, it is not a case of a _defective_ drive. This does not
eliminate the possibiity of 'non standard' behavior (where the drive is
'working as the manufacturer intends'), with Unbuntu having an embedded
'work around'.
I've had too much experience with *REALLY*weird* problems to dismiss
-anything-, out of hand. 30+ years ago, I discovered inadvertently)
a very specific set of circumstances where I could render a mainframe
_completely_ unusable -- by simply _rewinding_ a mag tape, as a
regular user. The only recovery was a re-boot of the mainframe. If
folks caught it _early_enough_, a reboot directive from the operator
console was effective. If it developed a bit further, the *only*
recourse/remedy was the 'big red button'. To add to the 'fun', this
particular vulnerability was *confirmed* to exist on at least three
separate, unrelated, operating systems running on _incompatible_
hardware.
> Unfortunately, the "workaround" of running mt -fsf
> after every file read
if it worked, 'mf -bsf' after every _write_ would be a better solution. <grin>
But it probably suffers from the same 'not really usable' defect.
> isn't really usable workaround.....I need the tape
> drive to work with bacula, not just running tars. Where do I go from here?
All I can contribute it the offspring of an rhinoceros mating with an elephant.
In other words, "elephino'. <groan>
_I_ have no clue what 'bacula' is -- sounds sort-of like a Transylvanian
back-up utility. One with 'fangs' init, and issues with mirrors. <grin>
Further troubleshooting gets _really_ deep, really quickly. Probably
involves 'instrumenting' the suspect drivers, to see -exactly- whac
calls to what driver are made,and inwhat order. May need an equivalent
of 'tcpdump' for the SCSI bus, too.
Sorry I can't be more help, I don't know specifics of FreeBSD internals,
but I've had a _lot_ of experience with tape handling (as a user) especially
tapes in unknown/non-standard formats.
I've *seen* so-called 'streaming' tape drives that _did_not_ support any
'reverse' direction action other than rewind'.. The cntroller _in_the_drive_
*lied* to the computer, when two tape marks in a row were 'written' by
the computer. the 2nd one wasn't actually put on the tape, although the
drive told the computer it had bin. Ditto for the backspace command following
the 2nd tape mark. If the next operation was a 'write', everything was
copacetic. If a 'reind', or 'rewind and unload', a tape mark was written
first. any 'backspace' command _other_ than the one immediately following
the attempt to write two tape marks, resulted in a 'hardware error' status,
and the drive dropping off-line.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201108270043.p7R0hul1028575>