Amanda-Users

Re: tar's default block size & shoe-shinning

2006-06-19 05:11:28
Subject: Re: tar's default block size & shoe-shinning
From: Joshua Baker-LePain <jlb17 AT duke DOT edu>
To: Cyrille Bollu <Cyrille.Bollu AT fedasil DOT be>
Date: Mon, 19 Jun 2006 05:02:38 -0400 (EDT)
On Mon, 19 Jun 2006 at 10:05am, Cyrille Bollu wrote

Could someone tell me if there are any possibilities to change the block
size tar is using when backuping with amanda?

I'm asking this because we have recently bought an IBM ULTRIUM-TD3 LTO3
drive here and Amanda reports an average write rate of only 17MB/s (when
the maximum speed should be 40 MB/s uncompressed). Which most probably
means that the drive is shoe-shinning...

Actually, native speed of LTO3 is 80MB/s, but it can throttle back to 1/2 that without shoeshining. So 40MB/s is the slowest you want to see.

I think, tar's default block size of 10k is the most limiting factor since
the constructor recommends a block size of 64kb and tests with "dd"
reported a transfer speed of 33MB/s with bs=64k and only reports a 25MB/s
with bs=10k.

Amanda doesn't 'tar' directly to tape, so it's not tar's blocksize you need to change. Amanda does its writing to tape with a default blocksize of 32KiB. To change that, you'll need to recompile amanda and specify the --with-maxtapeblocksize option to configure. With my LTO3 drive, I compile amanda with --with-maxtapeblocksize=2048.

After recompiling amanda, you can change the blocksize in the tapetype. Mine says "blocksize 2048", for a 2MiB blocksize. My backups generally tape at >60MiB/s.

bs          time (sec)      calculated speed (MB/s)
===================================
64k                   95                                   33,7
32k                 100                                   32
10k                 130                                   24,6
4k                   173                                   18,5
1k                   409                                    7,8

(results from the command "time dd if=/dev/sda2 of=/dev/nst0 bs=<var1>
count=<var2>". Where <var2> is calculated so that <var1>*<var2>=3200MB)

*All* of those speeds are too slow, so you probably want to look at bigger blocksizes. Also note that there's no way a single disk can both accept backups from over the network *and* keep an LTO3 drive streaming. I drive my LTO3 drive with a 4-disk RAID0, and I'm looking at going bigger so I can use the 2nd drive in my library simultaneously.

--
Joshua Baker-LePain
Department of Biomedical Engineering
Duke University