Paul Elliott wrote (2015/12/02):
> I would be interested to hear what block sizes other LTO5/6 users are
> using?
LTO-5/SAS on FreeBSD: I still use Maximum Block Size = 65536, because
333 MB/s transfer rate is sufficient for me. I have tried this small
script
---
#!/bin/sh
B=131072
C=32768
whil
Dan Langille wrote (2015/12/02):
> I had not considered that. In my case, I backup to local HDD (ZFS array)
> for long term storage. Right after those jobs finish, I copy to tape.
> Sounds like I need to implement spooling now. Fortunately, my full
> backups are only about 400GB. I think I can get
Hello,
Note: btape does not spool -- it writes directly to the tape. When it
is writing random data, you may find that your CPU is maxed out.
The speeds you see are quite reasonable in my opinion. It is unusual
that one will reach the theoretical maximum speed.
I recommend that you stick with
> On Dec 2, 2015, at 10:04 AM, Alan Brown wrote:
>
> On 02/12/15 12:14, Paul Elliott wrote:
>
>>> Maximum block size = 2M
>>
>> Have you experienced any issues with that block size?
>
> Only when the drives/tapes are dirty and then you get excess errors on all
> block sizes anyway.
>
>
On Wed, 02, Dec, 2015 at 03:04:07PM +, Alan Brown spoke thus..
> On 02/12/15 12:14, Paul Elliott wrote:
> >> Maximum block size = 2M
> >Have you experienced any issues with that block size?
> Only when the drives/tapes are dirty and then you get excess errors on all
> block sizes anyway.
>
On 02/12/15 12:14, Paul Elliott wrote:
>> Maximum block size = 2M
>
> Have you experienced any issues with that block size?
Only when the drives/tapes are dirty and then you get excess errors on
all block sizes anyway.
Because entire blocks are rewritten if there is an error, "tape waste"
Hi Alan,
On Wed, 02, Dec, 2015 at 11:46:40AM +, Alan Brown spoke thus..
>You should also consider doing the following in bacula-sd tape drive
>stanzas
> Maximum File Size = 16G
> Maximum Network Buffer Size = 262144
> Maximum block size = 2M
Have you experienced any iss
>> For LTO, the Spool disk MUST be at least least one SSD, preferably a
stripe of them on as fast a controller as you can afford. Standard disks
simply can't keep up with tape drives.
> I had not considered that. In my case, I backup to local HDD (ZFS
array) for long term storage. Right after thos
On Nov 30, 2015, at 12:18 PM, Alan Brown wrote:
>
>> On 30/11/15 16:57, Christoph Litauer wrote:
>> Hi Alan,
>>
>> maybe this is an important hint …
>> I thought btape doesn't use a disk at all. Instead it uses on-the-fly
>> generation of test data … does it?
>
> If it does, that could easil
Hi Christopher,
It sounds like you have other bottleneck issues elsewhere either with
your disks or tape drive/cabling which could be slowing things down.
You might want to check for firmware updates for the
tapes/disks/controllers. For LTO-4 your system needs to be able to
sustain at least 20
On 30/11/15 16:57, Christoph Litauer wrote:
> Hi Alan,
>
> maybe this is an important hint …
> I thought btape doesn't use a disk at all. Instead it uses on-the-fly
> generation of test data … does it?
If it does, that could easily be your bottleneck. /dev/random isn't
normally very fast.
> If
On 30/11/15 16:57, Christoph Litauer wrote:
> Hi Alan,
>
> maybe this is an important hint …
> I thought btape doesn't use a disk at all. Instead it uses on-the-fly
> generation of test data … does it?
If it does, that could easily be your bottleneck. /dev/random isn't
normally very fast.
> If
Hi Alan,
maybe this is an important hint …
I thought btape doesn't use a disk at all. Instead it uses on-the-fly
generation of test data … does it?
If btape uses the configured spool directory I have to take a look at that
point.
> Am 30.11.2015 um 17:00 schrieb Alan Brown :
>
> On 30/11/15 15
On 30/11/15 15:32, Christoph Litauer wrote:
> Andrew,
>
> many thanks for this hint. I installed the IBM driver and found the tape
> drive testing tool itdt, too.
> Now, using itdt and the new driver there is an improvement:
> LTO6: 158 MB/s without compression, 177MB/s with compression
> LTO4: 27
Andrew,
many thanks for this hint. I installed the IBM driver and found the tape drive
testing tool itdt, too.
Now, using itdt and the new driver there is an improvement:
LTO6: 158 MB/s without compression, 177MB/s with compression
LTO4: 27 MB/s without compression, 128 MB/s with compression.
F
Are you using the IBM Linux tape driver? If not, I'd suggest installing
it vs the generic linux kernel's tape driver.
http://www-933.ibm.com/support/fixcentral/swg/selectFixes?parent=Tape%2Bdrivers%2Band%2Bsoftware&product=ibm/Storage_Tape/Tape+device+drivers&release=1.0&platform=Linux&function=a
Dear bacula users,
I recently recognized that my tape drives do not perform as expected. Neither
while used with bacula nor native with dd. I did many performance tests in the
meantime but could not figure out the reason. So may I ask in this group what
typical write speeds you have with your t
17 matches
Mail list logo