Re: Turn off amgtar sparse detection for better performance

I have 1 sparse DB file at 100MB, it is not worth supporting that for 1/4 backup speeds over my 16TB backup run.
If any of my users (only 2 of them) were to use TB sized sparse files they are not getting those files back on restore and a complementary ban.

Sure if you have lots of large VMs, then yes keep sparse support enabled for those DLEs but i would not have it enabled by default when it comes at such a large cost.
For me block de-duplication is a larger issue but sparse support does nothing for that anyways.

Anton "exuvo" Olsson
    [email protected]

On 2024-09-06 22:58, Jon LaBadie wrote:
> On Sat, Sep 07, 2024 at 01:19:03AM +1000, meku wrote:
>> Thank you for the amazing tip. I also benchmarked similar results: amgtar
>> was averaging 140MB/s with --sparse, and with sparse disabled it now
>> averages 600MB/s. I expect this will have a huge improvement on backup
>> times.
>>
>> On Sat, 31 Aug 2024 at 10:57, Exuvo <[email protected]> wrote:
>>
>>> I have been trying to figure out why tar run by amanda was so much slower
>>> than my manual tar runs.
>>> The culprit is tar --sparse (which is on by default in amgtar) which for
>>> me maxes out 1 CPU core and reduces tar's read speed to around 130MB/s for
>>> me on a ZFS filesystem with 1GB files.
>>> I turned that option off and now it can read at 500MB/s with only 30% CPU
>>> usage.
>>>
>>> I suspect this will also resolve the slow read speeds i have with lots of
>>> tiny files as tar was also capped on CPU there but i had assumed it was
>>> blocking on IO.
>>>
>
> Take these cautionary comments as coming from someone uncertain of their accuracy.
> A sparse file is one which has some blocks to which no data has been written.
>
> For example, I had a UNIX Sys Adm whom I despised going round in circles trying
> to figure something out.  These were the days of GB sized disks being large.
> Being a control freak, he set the user file size limit (ulimit -f) to about 4MB.
> If you needed larger files you had to get dispensation from him.
>
> I wrote a C program that simply created a file, wrote one byte at the start.  It then "seeked" to 1TB, wrote one more byte, and closed the file.  To most command line programs it was a 1TB file, bigger than the
> user limit and 4 times bigger than the entire disk.  Do a wc, a cat, ls -l,
> etc and it was 1TB.  But it only used 2 of the millions of disk blocks available.  If you cat'ted the file, the system supplied a TB of null
> bytes between the two single characters I actually wrote to the file.
>
> So what would happen if you amanda-backed-up that file?  Without the
> --sparse flag of amgtar the system would efficiently supply a 1TB file with lots of null bytes.  If you compressed your backup, gzip would shrink those nulls to almost nothing.  But what would happen if you
> restored that file from backup?  You better have lots of room, you
> will get the entire 1TB file, null bytes included.  Nothing in the
> backup says it was originally sparse.
>
>
> I suggest you consider whether to use --sparse on a DLE by DLE basis.
> You may have some file systems (likely dedicated to a single application) that are likely to use sparse files.  Database managers for
> example.  Maybe Virtual Machines.  Maybe ???
>
> Check the effect of --sparse on them.  Time/speed, size, and VERY
> important, restoration.
>
> You may also want to delve deeper into gtar's use of --sparse.  It is
> configurable.  Here are 3 pieces from the man page.
>
>
>   --hole-detection=METHOD
>         Use METHOD to detect holes in sparse files.  This option implies --sparse.
>         Valid values for METHOD are seek and raw.  Default is seek with fallback
>         to raw when not applicable.
>
>   --sparse-version=MAJOR[.MINOR]
>         Set which version of the sparse format to use.  This option implies
>         --sparse.  Valid argument values are 0.0, 0.1, and 1.0. For a
>         detailed discussion of sparse formats, refer to the GNU Tar Manual,
>         appendix D, "Sparse Formats".  Using the info reader, it can be
>         accessed running the following command: info tar 'Sparse Formats'.
>
>   -S, --sparse
>         Handle sparse files efficiently.  Some files in the file system may have
>         segments which were actually never written (quite often these are database
>         files created by such systems as DBM).  When given this option, tar attempts
>         to determine if the file is sparse prior to archiving it, and if so, to
>         reduce the resulting archive size by not dumping empty parts of the file.
>
> Good Luck,
> Jon
>