linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marc MERLIN <marc@merlins.org>
To: Hugo Mills <hugo@carfax.org.uk>, linux-btrfs@vger.kernel.org
Subject: Re: Can you keep reflink relationship during a copy/backup to another filesystem?
Date: Fri, 7 Feb 2014 15:05:58 -0800	[thread overview]
Message-ID: <20140207230558.GA9265@merlins.org> (raw)
In-Reply-To: <20140129080514.GQ3314@carfax.org.uk>

[-- Attachment #1: Type: text/plain, Size: 2170 bytes --]

On Wed, Jan 29, 2014 at 08:05:14AM +0000, Hugo Mills wrote:
> On Tue, Jan 28, 2014 at 11:50:25PM -0800, Marc MERLIN wrote:
> > So I used to use hardlinks to do historical backups of the same filesystem
> > but I know it's preferable to use refllink with btrfs to avoid having too
> > many hardlinks.
> 
>    If you use btrfstune to set the "extended inode refs" option on the
> device, then there's no hardlink limit (and the limit was only on the

I'm not too clear about that part:
https://btrfs.wiki.kernel.org/index.php/Btrfstune
doesn't seem to match what you're saying.

> number of hardlinks to the same thing *in the same directory*).

I didn't catch the 'same directory' part. I used hardlinks.py to compare
all my files from many backups across filesystems and hardlink files
together if they were the same.
You're saying that I could have 500 hardlinks to the same file as long as
they are in 500 different directories, and that this is not a performance
problem or limitation for btrfs (maybe anymore? I could swear I had issues
with this in the past).

If the limit is now hardlinking many times to the same file in the same
directory, I don't actually have a need for that use case.
 
> > But if I need to backup this filesystem to another one some other way than
> > btrfs send/receive (let's say cp -a, tar, or rsync), is it correct to say
> > that reflink relationships will be lost and my data will take more space?
> > 
> > That is unless the target filesytem can do deduplication like btrs now can?
> > (I haven't tried it yet, but it's about time that I do)
> 
>    Correct.

Thanks.
I just noticed that on the fly deduplication wasn't in 3.12 yet, so I'm
better off keeping my hardlinks for backups since it's easy to keep that
relationship when copying my backup tree to a backup device (backups of
backups, of course, y'all don't do that? :) ).

Thanks,
Marc
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
                                      .... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/  

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 308 bytes --]

      reply	other threads:[~2014-02-07 23:05 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-29  7:50 Can you keep reflink relationship during a copy/backup to another filesystem? Marc MERLIN
2014-01-29  8:05 ` Hugo Mills
2014-02-07 23:05   ` Marc MERLIN [this message]

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=20140207230558.GA9265@merlins.org \
    --to=marc@merlins.org \
    --cc=hugo@carfax.org.uk \
    --cc=linux-btrfs@vger.kernel.org \
    /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).