You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In variable block mode, the byte count in write() determines the size
of the physical block on tape. When reading, the drive reads the next
tape block and returns to the user the data if the read() byte count
is at least the block size. Otherwise, error ENOMEM is returned.
Don't know how common this is, but this is something to keep in mind if tapeimgr fails on a tape. In theory support for variable-block tapes could be added by reading 1-block at a time, and then do a new blockSize estimation once a block results in read errors.
TODO: see if variable-block tapes can be emulated with mhvtl, and use that for testing.
It also implies that the 'filll failed blocks' option is likely to yield corrupted content for variable-block tapes.
SCSI tape drives can support variable block mode, fixed block mode, or both. Older drives typically support only fixed block mode. Newer drives often either support variable block mode only, or both variable block and fixed block modes.
So if true this means older tapes are unlikely to be affected.
The text was updated successfully, but these errors were encountered:
Apparently block size can be variable within a file that's written to tape, see:
https://github.com/torvalds/linux/blob/master/Documentation/scsi/st.rst
Don't know how common this is, but this is something to keep in mind if tapeimgr fails on a tape. In theory support for variable-block tapes could be added by reading 1-block at a time, and then do a new blockSize estimation once a block results in read errors.
TODO: see if variable-block tapes can be emulated with mhvtl, and use that for testing.
It also implies that the 'filll failed blocks' option is likely to yield corrupted content for variable-block tapes.
See also:
https://unix.stackexchange.com/a/366217/187090
and:
https://www.mkssoftware.com/docs/man4/tape.4.asp
which says:
So if true this means older tapes are unlikely to be affected.
The text was updated successfully, but these errors were encountered: