Your message dated Wed, 10 May 2006 19:57:58 +0200
with message-id <[EMAIL PROTECTED]>
and subject line Bug#308377: Close me
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--- Begin Message ---
Package: bacula-sd
Version: 1.36.2-2
Severity: normal


I noticed this change in behavior when I upgraded my system from kernel 
2.4.27 to 2.6.10. Attempting to position to the end of data on a tape in 
order to append backups no longer works:

<unmount>
<mount>
<run something>
09-May 16:02 hamster-sd: Volume "S12021" previously written, moving to 
end of data.
09-May 16:04 hamster-sd: ahbase02.2005-05-09_16.02.45 Error: Unable to 
position to end of data on device "/dev/nst0". Err=dev.c:494 ioctl MTEOM 
error on /dev/nst0. ERR=Input/output error.
<etc>

Everything works fine as long as I don't position to the end of the 
tape; for example, I can purge the volume and then bacula is happy to 
reuse it, writing from the beginning, and I can continue appending jobs 
until it fills up, just like I expected. Restores (where I position into 
the middle of the data) work fine too. I have run btest and it claims 
that everything is fine (and particularly the append tests all pass).

This problem started specifically when I upgraded my Linux kernel from 
2.4 to 2.6. Having spooling enabled or disabled does not affect the 
problem. Upgrading through the various 1.36.* versions of Bacula did not 
affect the problem.

Here is the device stanza from my /etc/bacula/bacula-sd.conf file:

Device {
  Name = TZ89
  Media Type = TZ89
  Archive Device = /dev/nst0
  AlwaysOpen = yes
  RemovableMedia = yes
  RandomAccess = no
  Spool Directory = "/var/spool/backup"
  Maximum Spool Size = 10000000000 # A little below 10G
  Maximum Job Spool Size = 2000000000 # A little below 2G
}


-- System Information:
Debian Release: 3.1
Architecture: alpha
Kernel: Linux 2.6.10-hamster.5b
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages bacula-sd depends on:
ii  bacula-common               1.36.2-2     Network backup, recovery and verif
ii  debconf                     1.4.30.13    Debian configuration management sy
ii  libacl1                     2.2.23-1     Access control list shared library
ii  libc6.1                     2.3.2.ds1-21 GNU C Library: Shared libraries an
ii  libcomerr2                  1.37-2       common error description library
ii  libgcc1                     1:3.4.3-12   GCC support library
ii  libkrb53                    1.3.6-2      MIT Kerberos runtime libraries
ii  libpq3                      7.4.7-6      PostgreSQL C client library
ii  libssl0.9.7                 0.9.7e-3     SSL shared libraries
ii  libstdc++5                  1:3.3.5-12   The GNU Standard C++ Library v3
ii  libwrap0                    7.6.dbs-8    Wietse Venema's TCP wrappers libra
ii  zlib1g                      1:1.2.2-4    compression library - runtime

-- no debconf information


--- End Message ---
--- Begin Message ---
Bailey, Scott wrote:
>
> Jose,
>
> I'm still waiting for a newer bacula release :-)
>
Go grab it while it still hot!!

deb http://devel.adv-solutions.net/debian unstable main
>
> but in the meantime I finally was able to track down the cause of this
> issue. My system uses the qla1280 SCSI driver for my TZ89 DLT4 drive,
> and it turns out this driver implements 30-second operation timeouts.
> On nearly any tape I used for real work, repositioning commands
> (either EOD or FSF) would take longer than 30 seconds to complete and
> consequently would get aborted.
>
> The problem didn't show up with "btape test" because it writes such a
> small amount of data that the drive is able to complete each of the
> positioning commands in less than 30 seconds and didn't trigger the
> "feature".
>
> I opened bug 366730 against the kernel source for this issue - but it
> is clear now that bacula is not contributing to the problem, so please
> close out my original bug report.
>
Ok. Thanks. Done (with this e-mail)


    J.L.


--- End Message ---

Reply via email to