| [ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
(This message will disappear, once this node revised.)
The data in an archive is grouped into blocks, which are 512 bytes. Blocks are read and written in whole number multiples called records. The number of blocks in a record (i.e., the size of a record in units of 512 bytes) is called the blocking factor. The ‘--blocking-factor=512-size’ (‘-b 512-size’) option specifies the blocking factor of an archive. The default blocking factor is typically 20 (i.e., 10240 bytes), but can be specified at installation. To find out the blocking factor of an existing archive, use ‘tar --list --file=archive-name’. This may not work on some devices.
Records are separated by gaps, which waste space on the archive media.
If you are archiving on magnetic tape, using a larger blocking factor
(and therefore larger records) provides faster throughput and allows you
to fit more data on a tape (because there are fewer gaps). If you are
archiving on cartridge, a very large blocking factor (say 126 or more)
greatly increases performance. A smaller blocking factor, on the other
hand, may be useful when archiving small files, to avoid archiving lots
of nulls as tar fills out the archive to the end of the record.
In general, the ideal record size depends on the size of the
inter-record gaps on the tape you are using, and the average size of the
files you are archiving. See section How to Create Archives, for information on
writing archives.
Archives with blocking factors larger than 20 cannot be read
by very old versions of tar, or by some newer versions
of tar running on old machines with small address spaces.
With GNU tar, the blocking factor of an archive is limited
only by the maximum record size of the device containing the archive,
or by the amount of available virtual memory.
Also, on some systems, not using adequate blocking factors, as sometimes imposed by the device drivers, may yield unexpected diagnostics. For example, this has been reported:
Cannot write to /dev/dlt: Invalid argument
In such cases, it sometimes happen that the tar bundled by
the system is aware of block size idiosyncrasies, while GNU tar
requires an explicit specification for the block size,
which it cannot guess. This yields some people to consider
GNU tar is misbehaving, because by comparison,
the bundle tar works OK. Adding -b 256,
for example, might resolve the problem.
If you use a non-default blocking factor when you create an archive, you
must specify the same blocking factor when you modify that archive. Some
archive devices will also require you to specify the blocking factor when
reading that archive, however this is not typically the case. Usually, you
can use ‘--list’ (‘-t’) without specifying a blocking factor—tar
reports a non-default record size and then lists the archive members as
it would normally. To extract files from an archive with a non-standard
blocking factor (particularly if you’re not sure what the blocking factor
is), you can usually use the ‘--read-full-records’ (‘-B’) option while
specifying a blocking factor larger then the blocking factor of the archive
(i.e., ‘tar --extract --read-full-records --blocking-factor=300’).
See section How to List Archives, for more information on the ‘--list’ (‘-t’)
operation. See section Options to Help Read Archives, for a more detailed explanation of that option.
Specifies the blocking factor of an archive. Can be used with any operation, but is usually not necessary with ‘--list’ (‘-t’).
Device blocking
Set record size to blocks*512 bytes.
This option is used to specify a blocking factor for the archive.
When reading or writing the archive, tar, will do reads and writes
of the archive in records of block*512 bytes. This is true
even when the archive is compressed. Some devices requires that all
write operations be a multiple of a certain size, and so, tar
pads the archive out to the next record boundary.
The default blocking factor is set when tar is compiled, and is
typically 20. Blocking factors larger than 20 cannot be read by very
old versions of tar, or by some newer versions of tar
running on old machines with small address spaces.
With a magnetic tape, larger records give faster throughput and fit more data on a tape (because there are fewer inter-record gaps). If the archive is in a disk file or a pipe, you may want to specify a smaller blocking factor, since a large one will result in a large number of null bytes at the end of the archive.
When writing cartridge or other streaming tapes, a much larger blocking factor (say 126 or more) will greatly increase performance. However, you must specify the same blocking factor when reading or updating the archive.
Apparently, Exabyte drives have a physical block size of 8K bytes. If we choose our blocksize as a multiple of 8k bytes, then the problem seems to disappear. Id est, we are using block size of 112 right now, and we haven’t had the problem since we switched…
With GNU tar the blocking factor is limited only
by the maximum record size of the device containing the archive, or by
the amount of available virtual memory.
However, deblocking or reblocking is virtually avoided in a special case which often occurs in practice, but which requires all the following conditions to be simultaneously true:
tar
invocation.
If the output goes directly to a local disk, and not through stdout, then the last write is not extended to a full record size. Otherwise, reblocking occurs. Here are a few other remarks on this topic:
gzip will complain about trailing garbage if asked to
uncompress a compressed archive on tape, there is an option to turn
the message off, but it breaks the regularity of simply having to use
‘prog -d’ for decompression. It would be nice if gzip was
silently ignoring any number of trailing zeros. I’ll ask Jean-loup
Gailly, by sending a copy of this message to him.
compress does not show this problem, but as Jean-loup pointed
out to Michael, ‘compress -d’ silently adds garbage after
the result of decompression, which tar ignores because it already
recognized its end-of-file indicator. So this bug may be safely
ignored.
tar might ignore the exit status returned, but I hate doing
that, as it weakens the protection tar offers users against
other possible problems at decompression time. If gzip was
silently skipping trailing zeros and also avoiding setting the
exit status in this innocuous case, that would solve this situation.
tar should become more solid at not stopping to read a pipe at
the first null block encountered. This inelegantly breaks the pipe.
tar should rather drain the pipe out before exiting itself.
Ignore blocks of zeros in archive (means EOF).
The ‘--ignore-zeros’ (‘-i’) option causes tar to ignore blocks
of zeros in the archive. Normally a block of zeros indicates the
end of the archive, but when reading a damaged archive, or one which
was created by concatenating several archives together, this option
allows tar to read the entire archive. This option is not on
by default because many versions of tar write garbage after
the zeroed blocks.
Note that this option causes tar to read to the end of the
archive file, which may sometimes avoid problems when multiple files
are stored on a single physical tape.
Reblock as we read (for reading 4.2BSD pipes).
If ‘--read-full-records’ is used, tar
will not panic if an attempt to read a record from the archive does
not return a full record. Instead, tar will keep reading
until it has obtained a full
record.
This option is turned on by default when tar is reading
an archive from standard input, or from a remote machine. This is
because on BSD Unix systems, a read of a pipe will return however
much happens to be in the pipe, even if it is less than tar
requested. If this option was not used, tar would fail as
soon as it read an incomplete record from the pipe.
This option is also useful with the commands for updating an archive.
Tape blocking
When handling various tapes or cartridges, you have to take care of selecting a proper blocking, that is, the number of disk blocks you put together as a single tape block on the tape, without intervening tape gaps. A tape gap is a small landing area on the tape with no information on it, used for decelerating the tape to a full stop, and for later regaining the reading or writing speed. When the tape driver starts reading a record, the record has to be read whole without stopping, as a tape gap is needed to stop the tape motion without losing information.
Using higher blocking (putting more disk blocks per tape block) will use
the tape more efficiently as there will be less tape gaps. But reading
such tapes may be more difficult for the system, as more memory will be
required to receive at once the whole record. Further, if there is a
reading error on a huge record, this is less likely that the system will
succeed in recovering the information. So, blocking should not be too
low, nor it should be too high. tar uses by default a blocking of
20 for historical reasons, and it does not really matter when reading or
writing to disk. Current tape technology would easily accommodate higher
blockings. Sun recommends a blocking of 126 for Exabytes and 96 for DATs.
We were told that for some DLT drives, the blocking should be a multiple
of 4Kb, preferably 64Kb (-b 128) or 256 for decent performance.
Other manufacturers may use different recommendations for the same tapes.
This might also depends of the buffering techniques used inside modern
tape controllers. Some imposes a minimum blocking, or a maximum blocking.
Others request blocking to be some exponent of two.
So, there is no fixed rule for blocking. But blocking at read time should ideally be the same as blocking used at write time. At one place I know, with a wide variety of equipment, they found it best to use a blocking of 32 to guarantee that their tapes are fully interchangeable.
I was also told that, for recycled tapes, prior erasure (by the same drive unit that will be used to create the archives) sometimes lowers the error rates observed at rewriting time.
I might also use ‘--number-blocks’ instead of ‘--block-number’, so ‘--block’ will then expand to ‘--blocking-factor’ unambiguously.
| [ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This document was generated on August 23, 2023 using texi2html 5.0.