So, this is still somewhat interesting (to me, at least). Thanks to Dan for
the suggestion!
Swapping the two tapes used for btape fixed the problem. Swapping them back
caused the problem to reappear.
"In the old days," I'd say that we had a bad tape. However, there aren't
any errors logged by the drive (this drive apparently logs device errors and
media errors separately; it's brand-new drive and tapes).
I asked about compression in my first message because I was wondering why I
was only getting ~50MB/sec throughput and ~800GB on the tape. The reason
for my curiosity is wondering whether btape either turns compression off or
is generating such random data as to be utterly incompressible (which I'm
told is actually somewhat harder than it looks).
My goal here is solely to ensure that our configuration is working properly,
and that there aren't any bugs that might bite us later in the process. I
have an inkling (it's just a hunch) that there's some boundary condition
that we reached that caused this error - that it has to do with the specific
capacity of this particular tape, and that somehow we're hitting an instance
where a buffer write is not successful but this isn't reflected properly to
the storage daemon. The other tape held slightly more than the first tape.
(If I'm right about this, it's one of those rare instances; especially I
would guess that Bacula generates data that is compressible so that there's
possibly less of a likelihood that this might happen - does anyone know if
this is true?). Otherwise, I think I'll go on with testing, but this should
be a good test case for whether something is actually wrong with the code.
Anyone who's looked at this in more detail that I have in a position to
offer any suggestions? Thanks!
On Mon, Feb 11, 2008 at 3:11 PM, K. M. Peterson <
[EMAIL PROTECTED]> wrote:
>
> On Mon, Feb 11, 2008 at 12:49 PM, Dan Langille <[EMAIL PROTECTED]> wrote:
>
> > K. M. Peterson wrote:
> > ...
> > > Error reading block: ERR=block.c:1008 Read zero bytes at 1180:0 on
> > > device "Drive-1" (/dev/nst0).
> >
> > Have you tried a different tape as the second tape?
> >
>
> Hi,
>
> No, I haven't. I only have two DLT-S4 tapes at the moment, but I'll swap
> them and rerun the 'fill' tonight.
>
> Also, the compression question was more along the lines of: with a volume
> capacity of 812GB, and a write speed of 45MB/sec I presume that the drive
> isn't compressing the data. This would either be because the drive isn't
> set properly (although tapeinfo says DataCompEnabled: yes) or because fill
> writes really random data that isn't compressible. So I was wondering which
> of these explanations is more likely.
>
> I also played with the blocksize directives. tapeinfo says that the drive
> can write 16MB blocks; that would presumably be the fastest way to write to
> tape. However, btape says that's too big a blocksize so I'm wondering
> whether there is an issue with the size that the kernel/device is set to
> use.
>
> But really I'd be happy if btape - fill doesn't throw an error, and I'd
> still like any suggestions of things to try.
>
> Thanks!
>
>
> >
> > --
> > Dan Langille
> >
> > BSDCan - The Technical BSD Conference : http://www.bsdcan.org/
> > PGCon - The PostgreSQL Conference: http://www.pgcon.org/
> >
>
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
