Seek is already the default if supported.
Anton "exuvo" Olsson
ex...@exuvo.se
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 docu
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, th
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 a
On Sat, 31 Aug 2024 02:52:20 +0200
Exuvo 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/
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 wrote:
> I have been trying to figure o
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
