3

I am restoring files from a tar archive on an LTO-7 tape to a locally mounted network share. If I directly restore to the share it runs very slowly (90 MB/s). When I use an additional buffer I get the maximum throughput of 280 MB/s. However I get a broken pipe warning:

mbuffer -s 1M -m 2G -i /dev/st0 | tar -xf -
mbuffer: warning: error during output to <stdout>: Broken pipe

Note that the tar archive was originally written with a blocking factor of 2048 (i.e. 1MB block size)

I guess this means that tar is exiting before it has received all the data (maybe the buffer became temporarily empty and tar thought the data is over?).

  1. How do I get around this? i.e. How do I ensure tar waits for all the data to be received from the buffer?

  2. Why is buffering actually needed in the first place? The connection is 10G, the destination disk is a very fast RAID. What is the underlying reason that causes the slowdown?

EDIT 02/07/2020

I added the blocking factor to the tar command and the warning doesn't come.

mbuffer -s 1M -m 2G -i /dev/st0 | tar -x -b 2048 -f -

But I'd still like to know why I get a broken pipe warning if this is not specified.

4
  • Why do you use such a strange program instead of using a better tar implementation? star includes a FIFO buffer since 30 years and does not need to waste CPU cycles while reading from a pipe.
    – schily
    Jul 1, 2020 at 18:42
  • i tried star fifo but I get memory allocation / segmentation errors if I specify a fifo size greater than 1g
    – swami
    Jul 1, 2020 at 18:55
  • There is no need for a huge FIFO. It just needs to be large enough to keep the I/O running at all time. Jul 1, 2020 at 19:28
  • There was a report to a star bug related t the fifo size yesterday that has been fixed yesterday and will be published soon. I now see, that report was from you, so you'll get a patch this day... If you see problems with more than 1g already, there is a bug in your OS. star fs=2000m ... works without problems and much more will work after the fix. Note that the FIFO is 30 years old, nobody had that amount of RAM 30 years ago and nobody reported the problem before.
    – schily
    Jul 2, 2020 at 5:58

1 Answer 1

-1

Your error message has a simple reason: the tar implementation you used did not read all data befre calling exit().

This is caused (as you did already find out yourself) by the fact that you did not tell it the real tape block size.

A typical tape, except for QIC cartriges is blocked and for higher performance, it is recommended to use a large block size. A block size > 126 kB is not recommended for exchange with other people but for a backup, it is OK to use 1MB as block size.

TAR on the other side is also specified as working block oriented, with a default block size of 10kB.

The EOF definiton for a TAR archive is two zeroed 512 blocks directly after the last file (which is where a new tar header is expected.

After that EOF indication, archive prcessing stops and unless these two zeroed blocks by chance appear in the last 10 kB of the tape data, there is unread input and this is why you get a broken pipe message.

If you use star, the FIFO is inside tar and as a result, the tape read code and the tar archive processing always have the same idea of the tape block size. Besides the fact that star is more effective in being fast, this avoids the problem that not all input data is consumed from a tar archive.

BTW: for optimal streaming, a FIFO buffer size is recommended that lasts for 10-30 seconds of data with the maximum tape speed. Until star has been completely enhanced to support a larger FIFO, I recommend you to call:

star fs=2000m ...

Note: -fifo is the default in star since 30 years. Also note that options like -shm are not recommended in special on Linux where the amount of memory with this facility is limited.

star is definitely faster than any other tar implementation. Keep however in mind, that if you are using a COW filesystem like ZFS or if your OS has a slow kernel buffering implementation, it is recommended for speed to disable fsync() calls via -no-fsync when in extract mode. This makes star as "unreliable" as other tar implementations ;-) by not being able to know whether a file is been safe on the background storage, but this speeds up extraction by a factor of 4 on ZFS or a tradidional filesyste with bad buffereing. ZFS however does not implement bad buffering, but just is only able to grant a specific filesystem state at a high expense.

You must log in to answer this question.

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