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 ---