Christian Krause wrote:
> To clarify: I do not mean to change the **record size**, which would result
> in an incompatible tar file. I am only interested in the buffer sizes that
> are used to read from and write to block devices.
This has been noticed.
BTW: could you please use for better re
Dear all,
First, I would like to thank you all for your prompt replies.
To clarify: I do not mean to change the **record size**, which would result in
an incompatible tar file. I am only interested in the buffer sizes that are
used to read from and write to block devices.
As far as I unders
bsdtar has a similar optimization.
It decouples reads and writes, allowing it to use a more optimal size for each
side.
When it opens an archive for writing, it checks the target device type. If
it’s a character device (such as a tape drive), it writes the requested blocks
exactly. When the
On Jul 18, 2018, at 9:03 AM, Ralph Corderoy wrote:
>
> Hi Christian,
>
>> $ stat -c %o data/blob
>> 2097152
> ...
>> **tar** does not explicitly use the block size of the file system
>> where the files are located, but, for a reason I don't know (feel free to
>> educate me), 10 KiB:
>
> Histor
Christian Krause wrote:
> Dear tar Community,
>
> We are using **tar** at our High-Performance Computing (HPC) at our research
> institute iDiv. The networked file system serving (scientific) data on our
> cluster is using a block size of 2 MiB:
>
> ```
> $ mkdir data
> $ dd if=/dev/zero bs=2M
Hi Christian,
> $ stat -c %o data/blob
> 2097152
...
> **tar** does not explicitly use the block size of the file system
> where the files are located, but, for a reason I don't know (feel free
> to educate me), 10 KiB:
Historic, that being 20 blocks where a block is 512 B. See `Blocking
Factor'
