Backup Central

Dear Amanda Users,

I have some question regarding tape blocksizes.

I inherited an amanda system with default (32k?) blocksize.

Then by doing some testing with dd bs=nk I found, that the Quantum LTO-4
tape drive honours the 128k blocksize with the fastest speed.

I have the following paramers set in amanda.conf:

--- 8< ---
define device top_drive {
tapedev "tape:/dev/nsa1"
device-property "BLOCK_SIZE" "131072"
}

define device bottom_drive {
tapedev "tape:/dev/nsa0"
device-property "BLOCK_SIZE" "131072"
}
tpchanger "chg-multi:{top_drive,bottom_drive}"

define tapetype LTO4 {
length 780 gbytes
filemark 3273 kbytes
speed 70 mps
blocksize 128 kbytes
}
--- 8< ---

As you can see there's BLOCK_SIZE device property, then there's
blocksize parameter for the tapetype.
Additionally the block size can be via 'mt -f /dev/nsa0 blocksize n' (on
FreeBSD).

Question 1)
If I set the blocksize to 128k via mt, then I can't read the tapes. Do
I need to set this up directly via mt.
If so, then do I have to re-initialize old tapes? (amrmtape, mt erase,
amlabel)?

Question 2)
Are both settings in amanda.conf required or one of them is superfluous?

Question 3)
Amanda inserts a 32k header, when writing a dump about the dump's meta data.
How is this affected, when using an offset other than 32k?
What will be the offset of the real (.tar) data?

Thanks for all constructive answers in advance,

Attila

--
Attila Bogár
http://www.linguamatics.com/

Attila Bogár wrote:
Dear Amanda Users,

I have some question regarding tape blocksizes.

I inherited an amanda system with default (32k?) blocksize.

Then by doing some testing with dd bs=nk I found, that the Quantum
LTO-4 tape drive honours the 128k blocksize with the fastest speed.

I have the following paramers set in amanda.conf:

--- 8< ---
define device top_drive {
tapedev "tape:/dev/nsa1"
device-property "BLOCK_SIZE" "131072"
}

define device bottom_drive {
tapedev "tape:/dev/nsa0"
device-property "BLOCK_SIZE" "131072"
}
tpchanger "chg-multi:{top_drive,bottom_drive}"

define tapetype LTO4 {
length 780 gbytes
filemark 3273 kbytes
speed 70 mps
blocksize 128 kbytes
}
--- 8< ---

As you can see there's BLOCK_SIZE device property, then there's
blocksize parameter for the tapetype.
Additionally the block size can be via 'mt -f /dev/nsa0 blocksize n'
(on FreeBSD).

Question 1)
If I set the blocksize to 128k via mt, then I can't read the tapes.
Do I need to set this up directly via mt.
If so, then do I have to re-initialize old tapes? (amrmtape, mt erase,
amlabel)?

Don't do that, the tape drive must be in variable block size.

Question 2)
Are both settings in amanda.conf required or one of them is superfluous?
The device_property BLOCK_SIZE have priority if it is set.

Question 3)
Amanda inserts a 32k header, when writing a dump about the dump's meta
data.
How is this affected, when using an offset other than 32k?
What will be the offset of the real (.tar) data?
The header is the first block, the data start on the second block.

Jean-Louis

Attila Bogár wrote:
Hi Jean,

On 25/03/11 18:05, Jean-Louis Martineau wrote:
Question 1)
If I set the blocksize to 128k via mt, then I can't read the tapes.
Do I need to set this up directly via mt.
If so, then do I have to re-initialize old tapes? (amrmtape, mt
erase, amlabel)?

Don't do that, the tape drive must be in variable block size.

My tape is currently in variable mode, though I can see the following
in my reports:
I never trust what user say, prove it, what's the output of: mt status

host1.linguamatics.com / lev 0 partial taper: Error writing block:
Short write on tape device: Tried 131072, got 65536. Is the drive
using a block size smaller than 131072 bytes?
Sometime it is the OS that is not configured to allow bigger block,
check the kernel configuration.

Try with another software, can you use dd to write 128k block on the tape?

Jean-Louis

Hi Jean,

On 25/03/11 18:05, Jean-Louis Martineau wrote:
Question 1)
If I set the blocksize to 128k via mt, then I can't read the tapes.
Do I need to set this up directly via mt.
If so, then do I have to re-initialize old tapes? (amrmtape, mt
erase, amlabel)?

Don't do that, the tape drive must be in variable block size.

My tape is currently in variable mode, though I can see the following in
my reports:

host1.linguamatics.com / lev 0 partial taper: Error writing block: Short write on tape device: Tried 131072, got 65536. Is the drive using a block size smaller than 131072 bytes?


What's causing this and how can I solve this issue?

Thanks in advance,
Attila

Hi Jean,

On 31/03/11 11:22, Jean-Louis Martineau wrote:
My tape is currently in variable mode, though I can see the following
in my reports:
I never trust what user say, prove it, what's the output of: mt status


[amanda < at > solo ~/bin]$ mt -f /dev/nsa0 status
Mode Density Blocksize bpi Compression
Current: 0x46 variable 0 disabled
---------available modes---------
0: 0x46 variable 0 0x1
1: 0x46 variable 0 0x1
2: 0x46 variable 0 0x1
3: 0x46 variable 0 0x1
---------------------------------
Current Driver State: at rest.
---------------------------------
File Number: 0 Record Number: 2 Residual Count 0

[amanda < at > solo ~/bin]$ mt -f /dev/nsa0 status
Mode Density Blocksize bpi Compression
Current: 0x46 variable 0 disabled
---------available modes---------
0: 0x46 variable 0 0x1
1: 0x46 variable 0 0x1
2: 0x46 variable 0 0x1
3: 0x46 variable 0 0x1
---------------------------------
Current Driver State: at rest.
---------------------------------
File Number: 0 Record Number: 2 Residual Count 0



host1.linguamatics.com / lev 0 partial taper: Error writing block:
Short write on tape device: Tried 131072, got 65536. Is the drive
using a block size smaller than 131072 bytes?
Sometime it is the OS that is not configured to allow bigger block,
check the kernel configuration.

Try with another software, can you use dd to write 128k block on the tape?

I wasn't clear sorry. The situation is, that amanda is vigorously
writing the tape with 128k blocks, but at some point it stops with this
cryptic message:

Excerpt from the report:

USAGE BY TAPE:
Label Time Size % DLEs Parts
Daily-31 6:34 20803M 2.7 4 4
Daily-32 2:58 654719M 86.5 146 146

NOTES:
taper: tape Daily-32 kb 669935059 fm 146 [OK]
taper: tape Daily-31 kb 17090742 fm 4 [OK]


I can supply the full taper.debug log in private if it helps or let me
know if you would like higher verbosity.

If I see the taper log, I can see, that it started to tape at 9:55am to
Daily-32, (I would be interested why didn't it start both tapes in
parallel, but this is a different issue). It tapes a lot of DLEs to
Daily-32 (bottom_drive).

At 12:40 I see the following:

Thu Mar 31 12:40:37 2011: taper: xfer_start size 0
Thu Mar 31 12:40:37 2011: taper: Starting<Xfer < at > 0x805810830 (<XferSourceHolding < at > 0x804a08dc0> -> <XferDestTaperSplitter < at > 0x804b51450>)>
Thu Mar 31 12:40:37 2011: taper: Final linkage:<XferSourceHolding < at > 0x804a08dc0> -(PULL_BUFFER)-> <XferElementGlue < at > 0x804a09510> -(PUSH_BUFFER)-> <XferDestTaperSplitter < at > 0x804b51450>
Thu Mar 31 12:40:37 2011: taper: Building type SPLIT_FILE header of 131072-131072 bytes with name='files.linguamatics.com' disk='/export/home/cambridge/user1' dumplevel=1 and blocksize=131072
Thu Mar 31 12:40:41 2011: taper: Amanda::Taper::Scribe preparing to write, part size 0, using no cache (PEOM will be fatal) (splitter) (no LEOM)
Thu Mar 31 12:40:41 2011: taper: xfer_start size 0
Thu Mar 31 12:40:41 2011: taper: Starting<Xfer < at > 0x8058c6fb0 (<XferSourceHolding < at > 0x804a08c10> -> <XferDestTaperSplitter < at > 0x804b51590>)>
Thu Mar 31 12:40:41 2011: taper: Final linkage:<XferSourceHolding < at > 0x804a08c10> -(PULL_BUFFER)-> <XferElementGlue < at > 0x804a09190> -(PUSH_BUFFER)-> <XferDestTaperSplitter < at > 0x804b51590>
Thu Mar 31 12:40:41 2011: taper: Building type SPLIT_FILE header of 131072-131072 bytes with name='files.linguamatics.com' disk='/export/home/cambridge/user2' dumplevel=1 and blocksize=131072
Thu Mar 31 12:43:28 2011: taper: empty write to tape; treating as LEOM early warning and retrying
Thu Mar 31 12:43:28 2011: taper: Device bottom_drive error = 'Error writing block: Short write on tape device: Tried 131072, got 65536. Is the drive using a block size smaller than 131072 bytes?'
Thu Mar 31 12:43:28 2011: taper: Device bottom_drive setting status flag(s): DEVICE_STATUS_DEVICE_ERROR
Thu Mar 31 12:43:33 2011: taper: Cancelling<Xfer < at > 0x8058c6fb0 (<XferSourceHolding < at > 0x804a08c10> -> <XferDestTaperSplitter < at > 0x804b51590>)>
Thu Mar 31 12:43:33 2011: taper: Amanda::Taper::Scribe preparing to write, part size 0, using no cache (PEOM will be fatal) (splitter) (no LEOM)
Thu Mar 31 12:43:33 2011: taper: xfer_start size 0
Thu Mar 31 12:43:33 2011: taper: Starting<Xfer < at > 0x8058867e0 (<XferSourceHolding < at > 0x804a08ca0> -> <XferDestTaperSplitter < at > 0x804b51590>)>
Thu Mar 31 12:43:33 2011: taper: Final linkage:<XferSourceHolding < at > 0x804a08ca0> -(PULL_BUFFER)-> <XferElementGlue < at > 0x804a09430> -(PUSH_BUFFER)-> <XferDestTaperSplitter < at > 0x804b51590>
Thu Mar 31 13:16:52 2011: taper: Building type SPLIT_FILE header of 131072-131072 bytes with name='files.linguamatics.com' disk='/export/home/cambridge/user2' dumplevel=1 and blocksize=131072
Thu Mar 31 16:31:21 2011: taper: Device top_drive error = 'Error writing block: Short write on tape device: Tried 131072, got 65536. Is the drive using a block size smaller than 131072 bytes?'
Thu Mar 31 16:31:21 2011: taper: Device top_drive setting status flag(s): DEVICE_STATUS_DEVICE_ERROR
Thu Mar 31 16:31:25 2011: taper: Cancelling<Xfer < at > 0x8058867e0 (<XferSourceHolding < at > 0x804a08ca0> -> <XferDestTaperSplitter < at > 0x804b51590>)>
Thu Mar 31 16:31:25 2011: taper: Amanda::Taper::Scribe preparing to write, part size 0, using no cache (PEOM will be fatal) (splitter) (no LEOM)
Thu Mar 31 16:31:25 2011: taper: xfer_start size 0
Thu Mar 31 16:31:25 2011: taper: Starting<Xfer < at > 0x805886790 (<XferSourceHolding < at > 0x804a08d30> -> <XferDestTaperSplitter < at > 0x804b51450>)>
Thu Mar 31 16:31:25 2011: taper: Final linkage:<XferSourceHolding < at > 0x804a08d30> -(PULL_BUFFER)-> <XferElementGlue < at > 0x804a090b0> -(PUSH_BUFFER)-> <XferDestTaperSplitter < at > 0x804b51450>
Thu Mar 31 16:31:25 2011: taper: Cancelling<Xfer < at > 0x805886790 (<XferSourceHolding < at > 0x804a08d30> -> <XferDestTaperSplitter < at > 0x804b51450>)>
Thu Mar 31 16:31:25 2011: taper: pid 39046 finish time Thu Mar 31 16:31:25 2011


As you can see, there's a DLE of user2, what Amanda can't tape neither
to the top drive or the bottom drive.
It's definitely not an EOM on the top_drive.

Let's see what's happening tomorrow morning. I have a feeling, this
issue emerged since I upgraded 3.2.1->3.2.2...

Thank you in advance for tracking this down,

Attila