Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230
yes, I am still trying to send the tarball, using mbuffer... in many cases it does prevent buffer underruns, it depends on the tape drive/tape type ( LTO-3...5 ), the type of data it is dealing with ( I rather do compression on a multicore system, than let the data being dealt with on the h/w provided compression ), plus it also gives me choice of using a different compression algorithm.... on small amounts of data, the improvement is questionable and often shows disadvantage, but I confirmed the backup to be much quicker when the tape drive does not get to buffer underruns... it stops being a "streamer" and continues to re-position the tape... this is not only bad for performance, but for the hardware/media itself. Adding eg. 8GB of buffer on both ends either prevents this from happening completely, or minimizes it.
I have no issue using the old version of tar for this purpose, but then this becomes limited to availability of tar (or even gcc) on a specific system.
What bothers me, is the difference of behavior directly from shell, and script... debugging might become a nightmare when dealing with similar cases, and maybe there is a single explanation that could potentially be applied to similar cases - I just wish/want to get to the bottom of it... it always helps when you know the cause, rather than just look for a workaround...
Thanks!
"They did not know it was impossible so they did it” - Mark Twain
sorry if not being clear enough....
My next step would be to
sending a test tarball from each tar version to the remote hosts tape
both with and without mbuffer
In memory of Ian Ashley Murdock (1973 - 2015) founder of the Debian project.