[Bacula-devel] Re: Fwd: Bacula append for 3592 and VTS

[Kern S. <ke...@si...>]

On Monday 11 July 2005 19:51, Adam Thornton wrote:
> More from Glenn, on why his patch is necessary:
>
> Begin forwarded message:
> > From: "Bily, Glenn" <Gle...@ei...>
> > Date: July 11, 2005 12:44:17 PM CDT
> > To: "'Adam Thornton'" <ath...@si...>
> > Subject: RE: Bacula append for 3592 and VTS
> >
> >
> > Adam,
> >
> > The reason Kern's code is not being used is because of MTIOCGET. My
> > code does not
> > rely on MTIOCGET (even though it ask). Kern's code does not deal
> > with a faulty
> > MTIOCGET. My code and Kern's code could/should? be folded together.
> > Look what
> > happens to the btape append test when I try to enable MTIOCGET:

Yes, in looking in more detail at your patch I see that you use the file 
position from the catalog if the dev_get_os_pos() fails.   

Unfortunately, this is not something that I can implement, because it 
eliminates a very important sanity test.  That is to compare the *actual* 
file position on tape to what is stored in the catalog.  They can get out of 
sync quite easily with something as simple as a power failure during a 
backup, or a broken catalog.  By relying on what is in the catalog, at some 
point, you will end up either overwriting valid data on the Volume, or Bacula 
(or more likely the user) will be confused when it tries to recover a data 
from a particular tape file and it does not find it.

Many OSes, such as Solaris, have two modes for MTEOM -- a so called fast mode 
where the OS looses track of what file it is at, and a slower mode, which is 
the default on most modern systems, where the OS keeps track of the file 
number by essentially doing a forward space file.  If you have such a 
feature, you might try turning on the slow version of MTEOM, then maybe 
MTIOCGET will return valid positions and you can use MTEOM.  Otherwise, I 
recommend you use Bacula's forward space file code, and figure out why the 
count is off -- it is probably because you need to enable BSFatEOM because 
your drive doesn't know how to stop at the right place, or is returning a 
non-standard Unix error status at the EOM.

Before trying the BSFatEOM, you might want to pull my current CVS code because 
I have added a test in the code for the non-standard Unix errno that your 
system returns when the read hits the EOM.  I happen to prefer the 
implementation on your system, but it *is* non-standard.

> >
> >                                     Glenn
> > Bily
> >
> > Department of Energy
> >
> > === Append files test ===
> >
> > This test is essential to Bacula.
> >
> > I'm going to write one record  in file 0,
> >                    two records in file 1,
> >              and three records in file 2
> >
> > btape: btape.c:440 Rewound "ntibm0" (/dev/ntibm0)
> > btape: btape.c:1519 Wrote one record of 64412 bytes.
> > btape: btape.c:1521 Wrote block to device.
> > btape: btape.c:470 Wrote 1 EOF to "ntibm0" (/dev/ntibm0)
> > btape: btape.c:1519 Wrote one record of 64412 bytes.
> > btape: btape.c:1521 Wrote block to device.
> > btape: btape.c:1519 Wrote one record of 64412 bytes.
> > btape: btape.c:1521 Wrote block to device.
> > btape: btape.c:470 Wrote 1 EOF to "ntibm0" (/dev/ntibm0)
> > btape: btape.c:1519 Wrote one record of 64412 bytes.
> > btape: btape.c:1521 Wrote block to device.
> > btape: btape.c:1519 Wrote one record of 64412 bytes.
> > btape: btape.c:1521 Wrote block to device.
> > btape: btape.c:1519 Wrote one record of 64412 bytes.
> > btape: btape.c:1521 Wrote block to device.
> > btape: btape.c:470 Wrote 1 EOF to "ntibm0" (/dev/ntibm0)
> > btape: btape.c:340 open_dev "ntibm0" (/dev/ntibm0) OK
> > btape: btape.c:440 Rewound "ntibm0" (/dev/ntibm0)
> > btape: btape.c:1058 Now moving to end of medium.
> > btape: btape.c:484 block.c:939 Read zero bytes at 0:0 on device /
> > dev/ntibm0.
> > We should be in file 3. I am at file 0. This is NOT correct!!!!
> >
> >
> > That appears *NOT* to have corrected the problem.
> >
> > Append test failed.
> >
> >
> > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> >
> > -----Original Message-----
> > From: Adam Thornton [mailto:ath...@si...]
> > Sent: Monday, July 11, 2005 12:26 PM
> > To: Glenn Bily
> > Subject: Fwd: Bacula append for 3592 and VTS
> >
> > Fom Kern; the weird thing is, it looks like you *do* have HW EOM set
> > in bacula-sd.conf.
> >
> > So, then: do we know why this patch is necessary, since the right
> > directive which should force it is already present in the config?
> >
> > Begin forwarded message:
> >> From: Kern Sibbald <ke...@si...>
> >> Date: July 11, 2005 11:16:56 AM CDT
> >> To: Adam Thornton <ath...@si...>
> >> Cc: bac...@li...
> >> Subject: Re: Fwd: Bacula append for 3592 and VTS
> >>
> >> On Monday 11 July 2005 17:41, Adam Thornton wrote:
> >>> This patch seems to fix appending on the (admittedly pretty weird)
> >>> IBM 34x0 (in this case, emulated 3480s in a virtual tape system
> >>> library) and 359x drives; I don't know if it's generally applicable
> >>> but I thought I'd pass it on to you.  I realize it's against
> >>> 1.37.18,
> >>> not .25, but if it's something you'd consider putting into the
> >>> actual
> >>> source tree, I'd be happy to do whatever rewriting (if any: I
> >>> haven't
> >>> applied it to my tree yet)  it needs for more recent Baculas.
> >>>
> >>> It's pretty trivial: basically, using FSF to get there gets the tape
> >>> placed one file off with the IBM drivers--which is, yes, probably a
> >>> driver bug--but these drives know about EOM and apparently implement
> >>> it fine, so we use EOM if we have it.
> >>
> >> I don't see the need for this code, because the same code already
> >> exists a bit
> >> higher in the source.
> >>
> >> Unless there is something I don't understand, you simply setup your
> >> Device
> >> resource and either use the default or make sure you have Hardware
> >> End Of
> >> Medium set, and Bacula will use the MTEOM function.

-- 
Best regards,

Kern

  (">
  /\
  V_V