Hi,
we had exactly the same Issue with a Quantum LTO3. Surprisingly, "old"
tapes filles up to average of 400GB, new ones only to 250GB. First we
thought about having a tape-vendor issue, because the new ones were from
a different vendor than the old ones.
But in the end, the loader/ tape drive was defective. Found that out by
using a Test-Tool provided by Quantum. After the tool reported the same
capacity limit of ~230GB for two different, new tapes, Quantum replaced
the complete loader without any complaints. Since then w have a capacity
around 550GB, which is quite ok.
Regards, Robert
Am 01.09.2011 18:17, schrieb Stefan Michael Guenther:
> Hi Alan,
>
> THANKS for the long list of suggestions! It will check this during the next
> days and hopefully send positive results to the list.
>
> Stefan
>
> -----Ursprüngliche Nachricht-----
> An: Stefan Michael Guenther<s.guent...@in-put.de>;
> CC: John Drescher<dresche...@gmail.com>; bacula-users@lists.sourceforge.net;
> Von: Alan Brown<a...@mssl.ucl.ac.uk>
> Gesendet: Do 01.09.2011 18:10
> Betreff: Re: [Bacula-users] Who is right about the tape size: Bacula or
> the tapeloader??
>> Stefan Michael Guenther wrote:
>>> Hi,
>>>
>>>> you do not impose a limit on how many bytes that bacula can write to a
>>>> tape bacula will write as many bytes as it can up until it hits the
>>>> first tape write error. At this point bacula assumes the tape is full.
>>>> Check your dmesg to see if there are any problems. Also try a brand
>>>> new LTO3 tape.
>>>>
>>> here is the corresponding output of dmesg:
>>>
>>> [ 7.806343] st 3:0:1:0: Attached scsi tape st0
>>> [ 7.806345] st 3:0:1:0: st0: try direct i/o: yes (alignment 512 B)
>>> [ 3295.705344] st0: Block limits 1 - 16777215 bytes.
>>> [ 3299.906724] st0: Failed to read 65536 byte block with 64512 byte
>>> transfer.
>>> [ 3856.794626] st0: Failed to read 65536 byte block with 64512 byte
>>> transfer.
>>> [ 4027.852762] st0: Failed to read 65536 byte block with 64512 byte
>>> transfer.
>>> [ 4173.406028] st0: Failed to read 65536 byte block with 64512 byte
>>> transfer.
>>>
>>> And, yes, we already tried it with a brand new tape - same result.
>>
>> 1: As others have stated, "Maximum Volume Bytes" should not be used on
>> tape volumes.
>>
>> 2: Nor should "Maximum Block Size" - this is imposing significant
>> overheads all by itself and is intended for old-school tape drives using
>> fixed block sizes. Avoid using unless you really have to. (You may find
>> tapes written using this parameter are not readable once it is removed.
>> It is best to run full backups on everything if you remove this setting)
>>
>> 3: In addition I would not use "Maximum Volumes" or "Maximum Volume
>> Jobs" unless you have specific reasons for them.
>>
>> 4: I would add "Maximum File Size = 10GB" (This is the size of each file
>> block on the tape. The default is 1Gb, which is a bit small for LTO3 and
>> newer.
>>
>> 5: Make sure the max network buffer size is the same everywhere and
>> don't exceed 65536. (If this is changed older tapes written with
>> different values will not be readable)
>>
>> 6: find the matching /dev/sg for your tape drive and Use "smartctl -H
>> -d scsi -l error /dev/sg{X}" to see if any errors are being reported
>> after tape write
>>
>> 7: Run a cleaning tape through the drive.
>>
>> 8: Make sure your spooling is working ok (best method is to use
>> dedicated spool drive(s) - ssds are better for keeping up with LTO demands.
>>
>> 9: What size files are you backing up? Smaller files will result in less
>> data being reported due to fixed per-file overheads which bacula doesn't
>> report as part of the save set.
>>
>> Notes:
>>
>> The GB sizes quoted on LTOs are decimal based, so the maximum
>> uncompressable data you'll fit on a LTO3 is about 380GiB.
>>
>> If you are backing up a lot of small files it's not uncommmon to lose
>> another 20-25%.
>>
>> Using fixed block sizes will eat a lot of tape in blocking overheads
>>
>> LTO uses a serpentine layout, so getting 250Gb means that your drive has
>> spooled to the end of the tape and back at least 4-5 times. That in turn
>> means that not reaching the uncompressed maximum is down to losing tape
>> into overheads (see below) or error rewrites due to vibration or
>> dirty/misaligned heads - LTO drives have separate read/write heads and
>> read data as soon as it's written in order to detect errors/rewrite the
>> data - if this is occuring then you'll see it using smartctl.
>>
>>
>>
>>
>>
> ------------------------------------------------------------------------------
> Special Offer -- Download ArcSight Logger for FREE!
> Finally, a world-class log management solution at an even better
> price-free! And you'll get a free "Love Thy Logs" t-shirt when you
> download Logger. Secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsisghtdev2dev
> _______________________________________________
> Bacula-users mailing list
> Bacula-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bacula-users
------------------------------------------------------------------------------
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better
price-free! And you'll get a free "Love Thy Logs" t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
