Re: [Dar-support] Slow dar_split backup speed

[Tsukasa <ts...@pr...>]

Hi Denis,

I never had any issues rewinding after the last volume, even when using 
the 2.5.14RC1. In the beginning I tested the drive with 2.5.13, writing 
small archives with random sizes and could rewind without any issues.

Regards,
Tsukasa


On 10/01/2018 20:27, Denis Corbin wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 09/01/2018 22:59, Tsukasa wrote:
>> Hi All,
> Hi Tsukasa,
>
> first, thank you for this feedback, and at all a happy new year!
>
>> Somehow the last discussion between Denis and me ended up as a
>> private email thread, so I'm copy-pasting part of my last reply,
>> which is a summary of how dar and dar_split work with LTO drives
>> (and most likely many other tape drives) now, with the fixed
>> version 2.5.14.
>>
>> I made another multi-volume backup using version 2.5.14, and it
>> all works perfectly now. When the end of a tape is reached, it
>> immediately stops accessing the drive, displays the message to
>> change media, and continues on the next tape without any issues. No
>> crc error occured upon verification this time. Another nice detail
>> is, that while the message is displayed, i can now control the
>> drive using the mt command from another terminal. This didn't work
>> before the fix. I had to rewind and eject using the hardware eject
>> button, because mt detected the drive state as busy.
> This is a side effect (OK, a positive one): dar_split reads and writes
> somehow large block of data. Upon a write failure with the "ENOSPC"
> code ("no space left on device") returned by the write() system call,
> dar_split assumed it was not possible to write data any further and
> thus it had fulfilled the device (the tape here). But this was an
> error, if the block of data given to write() is larger than the
> available space, the write() system call does not do anything at all
> but returns ENOSPC in that situation too, while some space remains on
> tape.
>
> When ENOSPC is retured by the write() system call, the fix consists in
> retrying to write the same data but by half the previous amount. If
> that fails again, the amount is again divided by 2 up to a size of one
> byte. And if writing one byte data fails, only then dar_split assumes
> the tape to be fulfilled.
>
> I suspect that the LTO drive writes data per block of fixed size and
> if the amount of data given for writting is not an integer number of
> blocks, the remaining is kept pending waiting for more data to come.
> This would explain why in that situation mt refuses to rewind the tape
> due to this pending data to be written onto tape.
>
> Thanks to the fix, the tape is now filled at maximum, which should
> correspond to an integer number of block at drive level, so the mt
> command can rewind the tape.
>
> I have thus a question regarding the last tape of an archive splitted
> by dar_split: as it is quite improbable that the last byte written by
> dar_split ends at an LTO block boundary, do you have any problem to
> get mt rewinding the last tape of an archive set?
>
>> So, yes, there is nothing left to complain about. The new display
>> of written amount of data is very useful to plan ahead how many
>> tapes I need. I added '|& tee textfile.log' to the command line to
>> log this.
>>
>> Regards, Tsukasa
>>
> Cheers,
> Denis
>
>> [...]
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQIVAwUBWlZpOQgxsL0D2LGCAQjAPRAAtgB6boG2AzLIcQCD4LA29oKGXLdlLtqt
> LNNqlzRd1HCg7kPDMztsdCSmjsseewT9iMYr0voJCtn97WObVG+rkheP67xrs6D8
> v+S3vXUzk0/OEyEodXUpBUmLrgYHWwAMhUrO6XKbd7Z53OlgdQJk27BDPMEB5jmH
> 0BNuocwS6q8S6qqSf0Z5BB4zu5PF+tK/wLk2Ef+QOHn+bcsO+CGCnGaNXG0supxJ
> /f/zmQsJtsDG1qggbbaCSu1ZDGgng4T/4qfJ8A4K2Gib7cMw5I0QLkHpy18QSId1
> Aog21PMWjgVz+FSMNCCF0jafLr5lshjeWuKNVWz9yFd+IuEEGgT3M/YVS/prKsS6
> oh13whyHIqg+vNlx31Xwq52bpTlGpArvtEwOORdBerXIskGEDw0khK6QiX5w3wcO
> UPOdlGsTIL7x0Kw1q9t0b0DaOvptvdy61tS5RopmdP2VUNoSdGf2IT5lv9Pv5WUD
> kPGg+jMZi5nsAPtTpPqHoVoMmiyvfOV3tto1uD6ml4bcXGyE+e1PimS2EXeDvMAr
> 0HCJHg2QyI8C/XhZ6obbRPFRSnjtueDrloZC65R28TSIhCIkgkyq2HmOISxxtwkD
> CVEkxUzHZTAkgU5yFb+FdJ7YwV7O6dWiVtns7GKWnrPTLdR+b8cNQYtwsznzm/MS
> jzA2ZU+/iw0=
> =xxXb
> -----END PGP SIGNATURE-----
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Dar-support mailing list
> Dar...@li...
> https://lists.sourceforge.net/lists/listinfo/dar-support