Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 20 Dec 2005 12:49:29 -0800
From:      Matthew Jacob <lydianconcepts@gmail.com>
To:        Kern Sibbald <kern@sibbald.com>
Cc:        freebsd-scsi@freebsd.org
Subject:   Re: Tape drive handling on FreeBSD
Message-ID:  <7579f7fb0512201249k595e2eai62467a0c0e670451@mail.gmail.com>
In-Reply-To: <200512201018.07905.kern@sibbald.com>
References:  <200512151122.34949.kern@sibbald.com> <200512192306.31821.kern@sibbald.com> <7579f7fb0512191520t484add63p40d81e2754897028@mail.gmail.com> <200512201018.07905.kern@sibbald.com>

next in thread | previous in thread | raw e-mail | index | archive | help
> The only problem I can imagine is if someone already uses O_NONBLOCK on a=
n
> open() call and expects it to fail if there is no tape in the drive.  Thi=
s
> seems a bit unlikely, but a bit of documentation can avoid most problems.



*cough*

Documentation didn't help you :-).

I'll try and do a bit of work on it over the next week or so but I can't
test until I get home and hook up a tape drive (and find a frickin' piece o=
f
DTL media for it).

Poke me periodically at my private address.

> Is the problem here that you *don't* want to do 'space to EOD' when EOM i=
s
> > issued? That is, you don't want to lose your actual relative tape
> position
> > information when seeking to append?
>
> Yes, exactly.  Since Bacula maintains the file/block positions of
> jobs/data in
> a catalog, it will refuse to append to a tape if the actual EOM of the
> tape
> does not agree with the catalog.  A discrepency can easily occur if, whil=
e
> writing a tape, the OS crashes (a power loss of course) ...



Can't use use block location stuff? Again- let's move this discussion to my
private mail address unless anyone else on freebsd-scsi wants to join in.



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