Alan Brown wrote:
On Mon, 17 Apr 2006, Wolfgang Denk wrote:
My best guess is that the problem is some sort of kernel SCSI lock race
condition. As a consequence, I would recommend that you concentrate on
writing lots of buffers as fast as you can, but from multiple processes,
possibly to the sa
On Mon, 17 Apr 2006, Wolfgang Denk wrote:
My best guess is that the problem is some sort of kernel SCSI lock race
condition. As a consequence, I would recommend that you concentrate on
writing lots of buffers as fast as you can, but from multiple processes,
possibly to the same or different dri
On Monday 17 April 2006 01:02, Wolfgang Denk wrote:
> Dear Kern,
>
> in message <[EMAIL PROTECTED]> you wrote:
> > All your reasoning is absolutely perfect up to this previous point. In
> > looking at the Bacula error messages that you list above, it is always an
> > I/O error writing a Bacula blo
Dear Kern,
in message <[EMAIL PROTECTED]> you wrote:
>
> All your reasoning is absolutely perfect up to this previous point. In
> looking at the Bacula error messages that you list above, it is always an I/O
> error writing a Bacula block that produces the problem. Once Bacula gets an
Argh..
On Sunday 16 April 2006 20:23, Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]> you wrote:
> > Then it sounds to me more like a bacula issue rather than the SCSI tape
> > driver.
>
> I disagree. We get pretty clear SCSI error messages (unexpected
> disconnect). No matter what a user app
In message <[EMAIL PROTECTED]> you wrote:
>
> Then it sounds to me more like a bacula issue rather than the SCSI tape
> driver.
I disagree. We get pretty clear SCSI error messages (unexpected
disconnect). No matter what a user application does, the SCSI driver
must never run into such a s
Wolfgang Denk wrote:
In message <[EMAIL PROTECTED]> you wrote:
I am more and more convinced that this is a subtel timing issue in
the SCSI tape driver layer.
Or possibly a bad cable/terminator...
No, definitely not. Believe me, I know what I'm doing, and this
wouldn't happen identi
In message <[EMAIL PROTECTED]> you wrote:
>
> > I am more and more convinced that this is a subtel timing issue in
> > the SCSI tape driver layer.
>
> Or possibly a bad cable/terminator...
No, definitely not. Believe me, I know what I'm doing, and this
wouldn't happen identically on
On Wed, 12 Apr 2006, Wolfgang Denk wrote:
As mentioned before, I see the same effect when changing the timing:
running the SD on a low end system (400 MHz P II) makes the problem
go away reliably - with h/w compression on.
I am more and more convinced that this is a subtel timing issue in
Wolfgang Denk wrote:
In message <[EMAIL PROTECTED]> you wrote:
I am more and more convinced that this is a subtel timing issue in
the SCSI tape driver layer.
Do you think it could be an overrun situation?
Overrun of what?
Sorry, nothing. Not thinking clear enough. Late hours here. Should
In message <[EMAIL PROTECTED]> you wrote:
>
> > I am more and more convinced that this is a subtel timing issue in
> > the SCSI tape driver layer.
>
> Do you think it could be an overrun situation?
Overrun of what?
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtim
Wolfgang Denk wrote:
In message <[EMAIL PROTECTED]> you wrote:
My last hypothesis is that it is due to using h/w compression. After I've
changed back to s/w compression I have not seen this phenomenon. When that said,
No, h/w vs. s/w compression is only indirectly involved. It changes
the
In message <[EMAIL PROTECTED]> you wrote:
>
> My last hypothesis is that it is due to using h/w compression. After I've
> changed back to s/w compression I have not seen this phenomenon. When that
> said,
No, h/w vs. s/w compression is only indirectly involved. It changes
the timing. With
Well, if they are all the same age and have been written to roughly an
equal number of times, that might be a possibility. I have had a few go at
around the same time (not simultaneously, but within a week or so of each
other).
I would have a little bit of trouble believing that HW compression
That was one thing I did think of and I did put in a cleaning tape and
ran it through. Will see if that clears it up.
I have trouble believing that 3-4 tapes were bad or corrupt all at once
so not sure that's the problem but I suppose stranger things have happened.
Deann
Ryan Novosielski wrote
I haven't tried that, but I will. If I can determine that this solves
the problem I'll report back to the list.
Thanks!
Deann
Diogo Melo wrote:
Have you tried to use the command "mt -f /dev/st0 erase" ? I think
this will ensure that all data of the tape has been erased, including
the eof ma
Have you tried to use the command "mt -f /dev/st0 erase" ? I think this will ensure that all data of the tape has been erased, including the eof marks.2006/4/12, Erik P. Olsen <
[EMAIL PROTECTED]>:Ryan Novosielski wrote:> Sounds to me like the media are going bad or your drive is dirty. Clean
> you
Ryan Novosielski wrote:
Sounds to me like the media are going bad or your drive is dirty. Clean
your drive and possibly try a brand new tape.
Probably not. I have had the same experience with brand new tapes and a cleaned
tape drive. See thread: When is a tape "Full"?).
My last hypothesis is
Sounds to me like the media are going bad or your drive is dirty. Clean
your drive and possibly try a brand new tape.
deann corum wrote:
> We're using Bacula 1.36.3 (yea, I know - old) on CentOS 3 (yea, I know
> - old) with AIT3 tapes (which store about 150 GB each) in an 8-tape
> changer (Sony S
We're using Bacula 1.36.3 (yea, I know - old) on CentOS 3 (yea, I know -
old) with AIT3 tapes (which store about 150 GB each) in an 8-tape
changer (Sony Stor-Station LIB-81).
Suddenly, Bacula has started marking tapes as 'Full' when only a few
files have been written to them and only a few GB.
20 matches
Mail list logo
