Just to close this thread out, I was able to erase the labels on the
tapes and have been successfully labeling tapes. Next stop, backups!
Thanks All!
Andrew
On Fri, Jun 19, 2015 at 3:47 PM, Bill Arlofski wrote:
> On 06/19/2015 03:58 PM, Andrew Noonan wrote:
>> Hi Bill,
>>
>> Yeah, I did th
On 06/19/2015 03:58 PM, Andrew Noonan wrote:
> Hi Bill,
>
> Yeah, I did that a few posts back.
heh, no idea how I missed that. I'll chalk it up to a very busy week!
> Unfortunately, there isn't a
> keen mapping that specifically connects the SCSI devices to the
> internal drive numbering t
Hi all,
After wrestling with a Dell TL4000 in the thread marked "Dell
TL4000 labeling timeout", it looks like the autochanger is going to be
fine thanks to the efforts of several people, especially Ana, on this
list.
Moving forward, I'm about to start running jobs to at first
backfill a
Hi Bill,
Yeah, I did that a few posts back. Unfortunately, there isn't a
keen mapping that specifically connects the SCSI devices to the
internal drive numbering that the changer uses, so commands against
the changer (mtx) would use the drive number, but commands against the
drive (mt) would
Hello Andrew,
Rather than use the /dev/nst0 and /dev/nst1 devices, you should use the device
nodes' "by-id" node names. These do not change over reboots the way the
/dev/nstX ones can.
First determine the scsi devices in the system and identify the "sg" node for
the library's changer device:
--
Hi Ana,
It looks like that is it. I flipped the devices that get pointed
to and I was able to attempt to label the disks. They had old labels
on them from some previous attempt, though, so now I'm going through
and erasing the labels, but that process is also completing so far
without error
Hello Andrew,
I'm affraid your /dev/nst1 is your first drive (índex 0) and /dev/nst0 is
your second drive (índex 1). From your mt status output, you have /dev/nst1
online with a tape loaded (i suspect this is the 44:02L6 tape). Could
you try changing this in your bacula-sd.conf (/dev/nst1 -> d
Hello,
I wrote the sample commands for /dev/st0 device. Did you change
queue_depth value for both tape drives ?
I am seeing that you have problem with /dev/st1 device as is shown on
attached output from SD debug (from your first mail in this thread).
If you changed queue_depth only for /dev/st0,
Hi Marcin,
I changed that setting, but that doesn't seem to have made a
difference in terms of the status output, or mtx-changer taking less
then the full timeout period to complete. The drive still shows as
DR_OPEN.
Thanks,
Andrew
On Fri, Jun 19, 2015 at 2:00 AM, Marcin Haba wrote:
> Hello,
>
Hello,
2015-06-18 4:35 GMT+02:00 Andrew Noonan :
> @Marcin - dmesg is clean
>
> @Ana - I ~think~ /dev/changer is created by udev, I'm not 100%. It's
> a symlink to sg19 in this case:
>
> lrwxrwxrwx 1 root root 4 Jun 10 17:06 /dev/changer -> sg19
> crw-rw 1 root disk 21, 19 Jun 10 17:06 /dev/s
10 matches
Mail list logo
