Thanks for the feedback Andrew!
Thank you Bill! It's always a pleasure to be here :).
Regards,
Ana
On Fri, Jun 19, 2015 at 6:02 PM, Andrew Noonan wrote:
> 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!
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 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
cat /proc/scsi/scsi:
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
Vendor: SEAGATE Model: ST373455SS Rev: S52C
Type: Direct-AccessANSI SCSI revision: 05
Host: scsi0 Channel: 00 Id: 01 Lun: 00
Vendor: SEAGATE Model: ST373455SS Rev: S52C
Type:
Hi Andrew,
Also, can you send us "cat /proc/scsi/scis" and "sg_map -x"?
Best regards,
Ana
On Thu, Jun 18, 2015 at 9:17 AM, Josh Fisher wrote:
>
>
> On 6/17/2015 10:35 PM, Andrew Noonan wrote:
> > @Marcin - dmesg is clean
> >
> > @Ana - I ~think~ /dev/changer is created by udev, I'm not 100%.
On 6/17/2015 10:35 PM, Andrew Noonan wrote:
> @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:
Most likely, udev got it right. Try mtx -f /dev/changer noattach status.
If that works, then try the load with the '
@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/sg19
Here are the tape drive parts of "lsscsi -l". I removed
Hello Andrew,
Is /dev/changer created by udev rules? Have you tried /dev/sgX instead? Can
you send us the output of the "lsscsi -l" command and "dmesg | grep
Attached"? Have you checked your drives/autochanger using just mtx/mt
commands to see if they are working? Which is your mtx version?
Best
Hello,
Do you have any errors in dmesg (hardware errors, bus reset, SCSI
errors ... etc.) ?
Best regards,
Marcin Haba (gani)
2015-06-17 21:56 GMT+02:00 Andrew Noonan :
> Hi all,
>
> It's taking a lot longer because of the higher timeouts, but the
> label is still failing with a termination.
Hi all,
It's taking a lot longer because of the higher timeouts, but the
label is still failing with a termination. If I understand it
correctly, the mtx-changer script is polling with 'mt' looking for the
$ready state, defined in the config file as ONLINE (for Linux). I'm
not seeing drive
Hi Ana,
Thanks for the reply. I'm adding those into the drives. BTW,
900 is the value. Having no real experience with these, is it
abnormal for a load to take the 10+ minutes, or is that reasonable?
My next step is to add those settings in, restart the SD, and attempt
to do a "label barcod
Hello Andrew,
You can find in the output of a "lsscsi -l" command the timeout for your
drives. Then you can configure 3 timeout directives for each one of your
two drives (LRADrive-1 e LRADrive-2):
Maximum Changer Wait = X
Maximum Rewind Wait = X
Maximum Open Wait = X
where X is the timeout valu
Hi all,
I'm almost completely new to tape. We've been doing disk-based
backups for years, but we now have a project where we want to offsite
hundreds of TB permanently, and have a Dell TL4000 (a rebranded IBM
3573-TL from the looks of it) with 2 ULT3580 LTO-6 drives. We're
running bacula 5.2. T
20 matches
Mail list logo
