Wolfgang Weisselberg wrote (in part):
> > How do I tell if I need it? I.e., does
> > ftape work any better with larger input blocks?
>
> Well, not with larger input blocks, but with a couple of megs
> of data to write held in reserve, there will be less shortages
> and thus repositionings just because the HD or cpio has a bit
> of latency ...
But once cpio (or whatever the program I use that writes to the driver) runs out,
it needs a lot of cpu and io time to refill its buffer. This will cause an
overrun, of course. If the buffer size is the length of a track on the tape
(exactly, but including the crc or whatever ecc is written), then I guess the tape
would not overrun, but it would wait while the program gathered up another block
of data.
> > I assume once they are larger
> > than ftape's internal buffers, it makes no sense to deliver it larger blocks.
>
> Well, no, see above.
>
> > So, how big are those buffers that ftape allocates itself 3 of? Obviously,
> > they must be at least 10240 bytes, but are they 30720 bytes or something?
>
> They are 32 Kb long each, aligned at a 32 Kb border. They are
> used for DMA. That's in the docs :-)
I read that, but somewhere else it suggests that it writes a block of 10240 bytes
at a time. I have not been able to reconcile these two numbers.
In the FAQ (that I got with the 3.04d version), question 3.10 asks what block size
to use with tar, and the answer was to use -b 58 which comes to 29,696 bytes. I
imagine the ecc bytes take (32,768 - 29,696) bytes. But when I run listtape, it
says the blocksize is 10,240 bytes. Furthermore, in 6.2 (of the 3.04d)
documentation, it says the default block size is 10240. Yet in 6.4 it says it
needs three 32k buffers.
>
>
> -Wolfgang
>
> --
> PGP 2 welcome: Mail me, subject "send PGP-key".
> Unsolicited Bulk E-Mails: *You* pay for ads you never wanted.
> How to dominate the Internet/WWW/etc? Destroy the protocols! See:
> http://www.opensource.org/halloween.html
--
Jean-David Beyer
Shrewsbury, New Jersey
Registered Linux User 85642.
S/MIME Cryptographic Signature