Re: Turn off amgtar sparse detection for better performance

Seek is already the default if supported.

Anton "exuvo" Olsson
    [email protected]

On 2024-09-08 00:13, Pieter Bowman wrote:
> Has anybody tried using the --hole-detection=seek option with GNU tar in conjunction with the --sparse option?  Does that indeed improve backup performance?
>
> That is documented in:
>
> https://www.gnu.org/software/tar/manual/html_node/sparse.html
>
>
> Pieter
>
> On 9/7/24 6:59 AM, Exuvo wrote:
>> 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
>>>