From: Martin Steigerwald <Martin@lichtvoll.de>
To: Jan Engelhardt <jengelh@inai.de>
Cc: linux-btrfs@vger.kernel.org, "Fajar A. Nugraha" <list@fajar.net>
Subject: Re: Workaround for hardlink count problem?
Date: Tue, 11 Sep 2012 11:16:32 +0200 [thread overview]
Message-ID: <201209111116.32850.Martin@lichtvoll.de> (raw)
In-Reply-To: <alpine.LNX.2.01.1209110121050.22773@frira.zrqbmnf.qr>
Am Dienstag, 11. September 2012 schrieb Jan Engelhardt:
>
> On Tuesday 2012-09-11 01:09, Martin Steigerwald wrote:
> >> > What about:
> >> >
> >> > - copy first backup version
> >> > - btrfs subvol create first next
> >> > - copy next backup version
> >> > - btrfs subvol create previous next
> >>
> >> Wouldn't "btrfs subvolume snapshot", plus "rsync --inplace" more
> >> useful here? That is. if the original hardlink is caused by multiple
> >> versions of backup of the same file.
> >
> >Sure, I meant subvol snapshot in above example. Thanks for noticing.
> >
> >But I do not use --inplace as it conflicts with some other rsync options I
> >like to use:
>
> It is a tradeoff.
>
> rsync "--inplace" leads to fragmentation which is detrimental for the
> speed of reads (and read-write-cycles as used by rsync) of big files
> (multi-GB) that are regularly updated, but it is probably even worse
> for smaller-than-GB files because percent-wise, they are even more
> fragmented.
>
> $ filefrag */vm/intranet.dsk
> snap-2012-08-15/vm/intranet.dsk: 23 extents found
> snap-2012-08-16/vm/intranet.dsk: 23 extents found
> snap-2012-08-17/vm/intranet.dsk: 4602 extents found
> snap-2012-08-18/vm/intranet.dsk: 6221 extents found
[…]
> snap-2012-08-25/vm/intranet.dsk: 7464 extents found
[…]
> snap-2012-09-09/vm/intranet.dsk: 10488 extents found
>
> Without --inplace (prerequisite to use -S) however, it will recreate
> a file if it has been touched. While this easily avoids fragmentation
> (since it won't share any data blocks with the old one), it can take
> up more space with the big files.
Yes. But I do not care as much as about sparse files. Cause for the
example I gave on a backup restore those sparse files would consume
about 1 GiB more on the SSD. Then I prefer to have some duplicated
files on the 2TB backup harddisk.
As for recreating the sparse nature of the files I´d have to format new
hardfiles and copy tons of mail files over within E-UAE. Thus I prefer
not to loose it on backup.
> >-ax --acls --xattrs --sparse --hard-links --del --delete-excluded --
>
> I knew short options would be helpful here: -axAXSH
> (why don't they just become the standard... they are in like almost
> every other rsync invocation I ever had)
Hey, I like those. I do not have to look up in the manpage what each
option means ;)
> > -S, --sparse
> > Try to handle sparse files efficiently so they take up
> > less space on the destination. Conflicts with --inplace
> > because it’s not possible to overwrite data in a sparse
> > fashion.
>
> Oh and if anybody from the rsync camp reads it: with hole-punching
> now supported in Linux, there is no reason not to support "-S" with
> "--inplace", I think.
Hmm, maybe I forward this to them.
Thanks,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
next prev parent reply other threads:[~2012-09-11 9:16 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-08 16:56 Workaround for hardlink count problem? Marc MERLIN
2012-09-10 9:12 ` Martin Steigerwald
2012-09-10 9:21 ` Fajar A. Nugraha
2012-09-10 23:09 ` Martin Steigerwald
2012-09-10 23:38 ` Jan Engelhardt
2012-09-11 9:16 ` Martin Steigerwald [this message]
2012-09-11 14:20 ` Arne Jansen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201209111116.32850.Martin@lichtvoll.de \
--to=martin@lichtvoll.de \
--cc=jengelh@inai.de \
--cc=linux-btrfs@vger.kernel.org \
--cc=list@fajar.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).