1

The 64 kiB blocksize is to maximize throughput and avoid "shoe shining".

mt -f /dev/nst0 setblk 64k

tar -c -v -R -b128 -f /dev/nst0 test_dir

returns:

bloc 0 : test_dir/
bloc 1 : test_dir/file_1.bin
bloc 204802 : test_dir/file_2.bin
bloc 2252803 : test_dir/file_3.bin
bloc 4300804 : test_dir/file_4.bin
...

But the block number in the tar output corresponds in 512 B blocksize, despite blocking factor giving 64 kiB blocksize (128 * 512).

And then, regardless of blocksize of the mt command (variable, 64 kiB).

The goal would to random access in the Tar-tape. Convert 64 kiB blocksize to 512 implies to trim.

Is there a way to matching records size of tar and mt ?

2
  • Excerpts of man pages of st command (more detailed as mt) : italic_Many programs (e.g., tar(1)) allow the user to specify the blocking factor on the command line. Note that this determines the physical block size on tape only in variable-block mode._italic Sep 25, 2015 at 13:56
  • But as I mentioned above, I tried with mt -f /dev/nst0 setblk 0. Viewed on forum : italic_tar/dd/whatever blocksize != (SCSI) tape device driver block _italic ([linuxmisc.com/14-unix-administering/b290ded6513059e2.htm]) Sep 25, 2015 at 14:05

2 Answers 2

1

UPDATE: Arg! So much for tests. Just did a full backup and tar with its default block/record size ran about 25% slower. So I'm back to using -b2048. Will try -b1024 and see how it goes.

Okay, just ran some tests. My advice is to set the tape block size to 0 (variable) and choose a tar block/record of your choice. I tested using a tape block size of 1M and 512K with matching tar record sizes (-b2048=1M -b1024=512K) and then I set the tape block size to 0 and tested using tar -b2048 and -b1024 and there was no difference. Then I ran a test with 'setblk 0' again but with a default tar block size of 512 (no -bxxxx in other words) for total record length of 10240 bytes and still no difference in performance.

I'm using a Quantum LTO-5. As long as you're substantially above 512 bytes (the LTO-5 default, I believe) you should be okay and it's unlikely you will experience any shoe-shining. IMO, the only reason to set the drive block size (instead of variable) is when its ignoring the software block size (record size in case of tar).

Note: the default block size for tar is 512 bytes x 20 for a total "record size" of 10240 bytes. Btw, my tests all finished within 12 seconds which totals ~141,000,000 bytes / second, the LTO-5 max throughput.

1

My results with --blocking-factor using tar to tape on multiple 200 to 300 GB size tar archives.

  • --blocking-factor 256 throughput 62 to 68 MiB/sec.

  • --blocking-factor 1024 throughput 87 MiB/sec.

I intend to do more experimentation with even larger blocking factors.

Above obtained with default hardware block size (I think variable) and no compression.

My equipment listed below:

  • HP EH958B StorageWorks Ultrium 3000 LTO-5 1.5/3TB SAS (Serial Attached SCSI) Half-Height External Tape Drive LTO5

  • TDK LTO-5 Ultrium Data Cartridge 1.5 TB / 3.0 TB LTO Ultrium-5 Tape

  • ATTO Technology ExpressSAS H680 PCIe 2.0 Low Profile 6Gb/s SAS HBA Card (External Ports) P/N: ESAS-H680-000

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .