Low ZFS read performance Disk->Tape
- Thread starter Lephisto
- Start date
nice great to hear
as for the slowdowns:
AFAICS from the logs you posted and what i observed there are 3 types of slowdowns that are expected now:
* when the tape has to reverse directions (this has to be done since for one track the tape has to reverse the direction a few times)
* when we sync/flush/commit (this should only once happen every 128GiB now)
* when the storage slows down, e.g. in your case i think that happens sometimes when the chunks are very small and the disk array can't keep up with that many IO requests (i also saw it here a correlation between lower speeds and higher chunk# in the logs)
Just note that in the final version of the first patch (with the threads) the name of the datastore property will change, so you have to either delete that again before upgrading to version with the patch applied or manually editing the config after upgrading since the gui will produce an error for an unknown option
afaik that depends on the individual hardware.
old (before LTO) drives had to do a full stop rewind and restart, which was not healthy, google "shoe-shining", "Back-Hitching" and tape drives.
i think LTO had DRM "data rate matching" from the start.
modern LTO drives can slow down, afaik IBM drives have like 7 speed's at what they can write to the tape.
HP has afaik a patent on "infinite" speeds for their drives.
(each vendor has different speeds for their drives)
and i think some even support (can be configured) to write "zero's" to the tape in favor to keep it running, but wasting space.
so in short on modern LTO drives buffer underrun should not be that often and not as harm full as in the past.
check the tech specs for your quantum drive, chances are that with your ~100MB/s you never had a buffer underrun.