Re: Cross subvolume "cp --reflink"?

[Noah Massey]

On Wed, Oct 19, 2016 at 12:52 PM, Andrei Borzenkov  wrote:
> I get "Failed to clone: Invalid cross-device link". Is it expected?

Yes, you cannot cross a MOUNTPOINT boundary with reflink.
Or, for that matter, btrfs subvolume snapshot.

> Basically this is (on openSUSE TW which has root on subvolume)
>
> mount -o subvol=/ /dev/vda1 /mnt
> btrfs sub create /mnt/var/cache
> cp -a --reflink=always /var/cache/* /mnt/var/cache
>

You *can* however cross subvolume boundaries within the same mountpoint.
Try (assuming your root subvolume is @root)

cp -a --reflink /mnt/@root/var/cache/* /mnt/var/cache

~ Noah
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Cross subvolume "cp --reflink"?

[Andrei Borzenkov]

19.10.2016 20:04, Hugo Mills пишет:
> On Wed, Oct 19, 2016 at 07:52:14PM +0300, Andrei Borzenkov wrote:
>> I get "Failed to clone: Invalid cross-device link". Is it expected?
>> Basically this is (on openSUSE TW which has root on subvolume)
>>
>> mount -o subvol=/ /dev/vda1 /mnt
>> btrfs sub create /mnt/var/cache
>> cp -a --reflink=always /var/cache/* /mnt/var/cache
>>
>> Kernel 4.7.5-1-default.
> 
>Yes, you're trying to copy across a mountpoint boundary. This isn't
> going to work. You'll need to mount subvolid=0 on /mnt, and then use
> the source and target of the cp *both* from within the /mnt subtree.
> 
>Reflink operations (including cp --reflink=always, and the
> reflink-aware mv) work across subvol boundaries, but not mount
> boundaries.
> 
>Hugo.
> 
Yes, figured that much too. Thank you!



signature.asc
Description: OpenPGP digital signature

Re: Cross subvolume "cp --reflink"?

[Hugo Mills]

On Wed, Oct 19, 2016 at 07:52:14PM +0300, Andrei Borzenkov wrote:
> I get "Failed to clone: Invalid cross-device link". Is it expected?
> Basically this is (on openSUSE TW which has root on subvolume)
> 
> mount -o subvol=/ /dev/vda1 /mnt
> btrfs sub create /mnt/var/cache
> cp -a --reflink=always /var/cache/* /mnt/var/cache
> 
> Kernel 4.7.5-1-default.

   Yes, you're trying to copy across a mountpoint boundary. This isn't
going to work. You'll need to mount subvolid=0 on /mnt, and then use
the source and target of the cp *both* from within the /mnt subtree.

   Reflink operations (including cp --reflink=always, and the
reflink-aware mv) work across subvol boundaries, but not mount
boundaries.

   Hugo.

-- 
Hugo Mills | For months now, we have been making triumphant
hugo@... carfax.org.uk | retreats before a demoralised enemy who is advancing
http://carfax.org.uk/  | in utter disorder.
PGP: E2AB1DE4  |  Eric Frank Russell, Wasp


signature.asc
Description: Digital signature

Cross subvolume "cp --reflink"?

[Andrei Borzenkov]

I get "Failed to clone: Invalid cross-device link". Is it expected?
Basically this is (on openSUSE TW which has root on subvolume)

mount -o subvol=/ /dev/vda1 /mnt
btrfs sub create /mnt/var/cache
cp -a --reflink=always /var/cache/* /mnt/var/cache

Kernel 4.7.5-1-default.

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: cross-subvolume cp --reflink

[Jérôme Poulin]

On Thu, Aug 16, 2012 at 5:41 PM, james northrup
northrup.ja...@gmail.com wrote:

 dunno if this thread is dead, but im inclined to patch in cp --reflink to 
 fdupes prog.
  It  currently does provide a poor-man's dedupe via md5sum and hardlink, or 
 delete.

 all the better if the distro-kernels can backport cross-snapshot reflinks 
 sooner than later.


I was also wondering if it is possible for a program like fdupes to
use BTRFS checksum to make searching for duplicates much faster as you
wouldn't need to calculate checksum if BTRFS own checksum was
mismatched between 2 groups of checksum blocks?
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: cross-subvolume cp --reflink

[james northrup]

On Mon, Aug 20, 2012 at 11:08 AM, Jérôme Poulin jeromepou...@gmail.com wrote:

 On Thu, Aug 16, 2012 at 5:41 PM, james northrup
 northrup.ja...@gmail.com wrote:
 
  dunno if this thread is dead, but im inclined to patch in cp --reflink
  to fdupes prog.
   It  currently does provide a poor-man's dedupe via md5sum and hardlink,
  or delete.
 
  all the better if the distro-kernels can backport cross-snapshot
  reflinks sooner than later.
 

 I was also wondering if it is possible for a program like fdupes to
 use BTRFS checksum to make searching for duplicates much faster as you
 wouldn't need to calculate checksum if BTRFS own checksum was
 mismatched between 2 groups of checksum blocks?

source in question is here..

http://code.google.com/p/fdupes/source/browse/trunk/fdupes.c

i consider cp --reflink an option for this code.  it doesn't strike me
as scalable at first glance and i wouldnt want to spend more than a
few minutes adding a  new option.

i like the idea of something a little more scalable to populate a
radix tree with extent-checksums abound and to link them without
regard to order or associative. i dont have this project in mind
myself.
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: cross-subvolume cp --reflink

[Marc MERLIN]

On Sun, Aug 19, 2012 at 12:08:01AM -0500, Mitch Harder wrote:
 On Fri, Aug 17, 2012 at 12:20 AM, Marc MERLIN m...@merlins.org wrote:
  On Thu, Aug 16, 2012 at 09:20:00PM -0700, james northrup wrote:
  dunno if this thread is dead, but im inclined to patch in cp --reflink
  to fdupes prog.  It  currently does provide a poor-man's dedupe via
  md5sum and hardlink, or delete.
 
  all the better if the distro-kernels can backport cross-snapshot
  reflinks sooner than later.
 
  So, I'd love for cp --reflink to bring back a deleted VM (huge file) from a
  snapshot back to trunk without duplicating it.
  But how would fdupes help? I can't hardlink between two snapshots, can I?
 
  gandalfthegreat:/mnt/btrfs_pool1# ln 
  usr_weekly_20120812_00\:02\:01/svn-commit.tmp  usr/test
  ln: failed to create hard link `usr/test' = 
  `usr_weekly_20120812_00:02:01/svn-commit.tmp': Invalid cross-device link
 
  So, is there anything user space can do without kernel support?
 
 
 A cross-subvolume copy patch has made it into 3.6_rc
 
 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=362a20c5e27614739c4
 
 This patch will allow cp --reflink across subvolumes, as long as the
 copy does not cross mount points.

I missed that, that's great news, thanks to all those involved in getting
this in.

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/  
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: cross-subvolume cp --reflink

[Mitch Harder]

On Fri, Aug 17, 2012 at 12:20 AM, Marc MERLIN m...@merlins.org wrote:
 On Thu, Aug 16, 2012 at 09:20:00PM -0700, james northrup wrote:
 dunno if this thread is dead, but im inclined to patch in cp --reflink
 to fdupes prog.  It  currently does provide a poor-man's dedupe via
 md5sum and hardlink, or delete.

 all the better if the distro-kernels can backport cross-snapshot
 reflinks sooner than later.

 So, I'd love for cp --reflink to bring back a deleted VM (huge file) from a
 snapshot back to trunk without duplicating it.
 But how would fdupes help? I can't hardlink between two snapshots, can I?

 gandalfthegreat:/mnt/btrfs_pool1# ln 
 usr_weekly_20120812_00\:02\:01/svn-commit.tmp  usr/test
 ln: failed to create hard link `usr/test' = 
 `usr_weekly_20120812_00:02:01/svn-commit.tmp': Invalid cross-device link

 So, is there anything user space can do without kernel support?


A cross-subvolume copy patch has made it into 3.6_rc

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=362a20c5e27614739c4

This patch will allow cp --reflink across subvolumes, as long as the
copy does not cross mount points.
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: cross-subvolume cp --reflink

[james northrup]

dunno if this thread is dead, but im inclined to patch in cp --reflink
to fdupes prog.  It  currently does provide a poor-man's dedupe via
md5sum and hardlink, or delete.

all the better if the distro-kernels can backport cross-snapshot
reflinks sooner than later.

On Sun, Apr 29, 2012 at 1:05 PM, Norbert Scheibner s...@gmx.net wrote:
 Am 29.04.2012, 01:53 Uhr, schrieb Hubert Kario h...@qbs.com.pl:


 On Sunday 01 of April 2012 11:42:23 Jérôme Poulin wrote:

 On Sun, Apr 1, 2012 at 11:27 AM, Norbert Scheibner s...@gmx.net wrote:
  Some users tested this patch successfully for week,s or months in 2 or
  3
  kernel versions since then, true?
 If this feature must be implented in VFS in another patch, why not
 just activate what works and make the future patch disable it again?


 Why would (should) it be impleemented in VFS? reflink copy is completely
 different from normal copy and hard link.


 I wouldn't make a VFS issue out of that. That should be another discussion.

 But:

 Subvolumes in btrfs are barriers *only* in btrfs and not visible in VFS.


 That is just a bug in my opinion, so it should work anyway, but to look at
 it from VFS point of view is strengthening me in wanting the outstanding
 patches integrated, as this feature could be supported by VFS in the future.


 IMHO it's strictly btrfs business and not supporting reflink copy between
 arbitrary directories is a bug.


 I don't know exactly, but I think ZFS is another candidate for cp
 --reflink. For some of the log-structured filesystems this could be usefull
 too, but I don't know if some of them already supports this or plan to
 support this in the future.

 Greetings
 Norbert

 --
 To unsubscribe from this list: send the line unsubscribe linux-btrfs in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: cross-subvolume cp --reflink

[Marc MERLIN]

On Thu, Aug 16, 2012 at 09:20:00PM -0700, james northrup wrote:
 dunno if this thread is dead, but im inclined to patch in cp --reflink
 to fdupes prog.  It  currently does provide a poor-man's dedupe via
 md5sum and hardlink, or delete.
 
 all the better if the distro-kernels can backport cross-snapshot
 reflinks sooner than later.
 
So, I'd love for cp --reflink to bring back a deleted VM (huge file) from a
snapshot back to trunk without duplicating it.
But how would fdupes help? I can't hardlink between two snapshots, can I?

gandalfthegreat:/mnt/btrfs_pool1# ln 
usr_weekly_20120812_00\:02\:01/svn-commit.tmp  usr/test
ln: failed to create hard link `usr/test' = 
`usr_weekly_20120812_00:02:01/svn-commit.tmp': Invalid cross-device link

So, is there anything user space can do without kernel support?

Marc

 On Sun, Apr 29, 2012 at 1:05 PM, Norbert Scheibner s...@gmx.net wrote:
  Am 29.04.2012, 01:53 Uhr, schrieb Hubert Kario h...@qbs.com.pl:
 
 
  On Sunday 01 of April 2012 11:42:23 Jérôme Poulin wrote:
 
  On Sun, Apr 1, 2012 at 11:27 AM, Norbert Scheibner s...@gmx.net wrote:
   Some users tested this patch successfully for week,s or months in 2 or
   3
   kernel versions since then, true?
  If this feature must be implented in VFS in another patch, why not
  just activate what works and make the future patch disable it again?
 
 
  Why would (should) it be impleemented in VFS? reflink copy is completely
  different from normal copy and hard link.
 
 
  I wouldn't make a VFS issue out of that. That should be another discussion.
 
  But:
 
  Subvolumes in btrfs are barriers *only* in btrfs and not visible in VFS.
 
 
  That is just a bug in my opinion, so it should work anyway, but to look at
  it from VFS point of view is strengthening me in wanting the outstanding
  patches integrated, as this feature could be supported by VFS in the future.
 
 
  IMHO it's strictly btrfs business and not supporting reflink copy between
  arbitrary directories is a bug.
 
 
  I don't know exactly, but I think ZFS is another candidate for cp
  --reflink. For some of the log-structured filesystems this could be usefull
  too, but I don't know if some of them already supports this or plan to
  support this in the future.
 
  Greetings
  Norbert
 
  --
  To unsubscribe from this list: send the line unsubscribe linux-btrfs in
  the body of a message to majord...@vger.kernel.org
  More majordomo info at  http://vger.kernel.org/majordomo-info.html
 --
 To unsubscribe from this list: send the line unsubscribe linux-btrfs in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
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/  
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: cross-subvolume cp --reflink

[Norbert Scheibner]

Am 29.04.2012, 01:53 Uhr, schrieb Hubert Kario h...@qbs.com.pl:


On Sunday 01 of April 2012 11:42:23 Jérôme Poulin wrote:

On Sun, Apr 1, 2012 at 11:27 AM, Norbert Scheibner s...@gmx.net wrote:
 Some users tested this patch successfully for week,s or months in 2  
or 3

 kernel versions since then, true?
If this feature must be implented in VFS in another patch, why not
just activate what works and make the future patch disable it again?


Why would (should) it be impleemented in VFS? reflink copy is completely
different from normal copy and hard link.


I wouldn't make a VFS issue out of that. That should be another discussion.

But:

Subvolumes in btrfs are barriers *only* in btrfs and not visible in VFS.


That is just a bug in my opinion, so it should work anyway, but to look at  
it from VFS point of view is strengthening me in wanting the outstanding  
patches integrated, as this feature could be supported by VFS in the  
future.



IMHO it's strictly btrfs business and not supporting reflink copy between
arbitrary directories is a bug.


I don't know exactly, but I think ZFS is another candidate for cp  
--reflink. For some of the log-structured filesystems this could be  
usefull too, but I don't know if some of them already supports this or  
plan to support this in the future.


Greetings
Norbert
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: cross-subvolume cp --reflink

[Hubert Kario]

On Sunday 01 of April 2012 11:42:23 Jérôme Poulin wrote:
 On Sun, Apr 1, 2012 at 11:27 AM, Norbert Scheibner s...@gmx.net wrote:
  Some users tested this patch successfully for week,s or months in 2 or 3
  kernel versions since then, true?
 If this feature must be implented in VFS in another patch, why not
 just activate what works and make the future patch disable it again?

Why would (should) it be impleemented in VFS? reflink copy is completely
different from normal copy and hard link.

Subvolumes in btrfs are barriers *only* in btrfs and not visible in VFS.

IMHO it's strictly btrfs business and not supporting reflink copy between
arbitrary directories is a bug.

Regards,
--
Hubert Kario
QBS - Quality Business Software
02-656 Warszawa, ul. Ksawerów 30/85
tel. +48 (22) 646-61-51, 646-74-24
www.qbs.com.pl

smime.p7s
Description: S/MIME cryptographic signature

Re: cross-subvolume cp --reflink

[David Sterba]

On Sun, Apr 01, 2012 at 10:27:38PM +0300, Konstantinos Skarlatos wrote:
 thats true, cp --reflink is much better. Also am I wrong that btrfs has 
 a limitation on the number of hard links that can only be fixed with a 
 disk format change?

There's patch in development to lift the limit and it does not need the
disk format change but adds an incompatibility bit.


david
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

cross-subvolume cp --reflink

[Norbert Scheibner]

Glück Auf!
I know its been discussed more then ones, but as a user I really would like to 
see the patch for allowing this in the kernel.

Some users tested this patch successfully for weeks or months in 2 or 3 kernel 
versions since then, true?

I'd say by creating a snapshot, it's nothing else in the end. More then one 
file or tree sharing the same data on disc, or am I wrong?

So why not?
Norbert
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: cross-subvolume cp --reflink

[Norbert Scheibner]

 On: Sun, 01 Apr 2012 18:30:13 +0300 Konstantinos Skarlatos wrote

 +1 from me too, i would save enormous amounts of space with a patch 
 like that, at least until dedupe is implemented. We could call it poor 
 man's dedupe

That's my point. This poor man's dedupe would solve my problems here very well. 
I don't need a zfs-variant of dedupe. I can implement such a file-based dedupe 
with userland tools and would be happy.

It's there, it's tested, it doesn't break another thing. Use it!

Greetings
   Norbert

--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: cross-subvolume cp --reflink

[Norbert Scheibner]

 On: Sun, 01 Apr 2012 19:45:13 +0300 Konstantinos Skarlatos wrote

  That's my point. This poor man's dedupe would solve my problems here
 very well. I don't need a zfs-variant of dedupe. I can implement such a
 file-based dedupe with userland tools and would be happy.
 
 do you have any scripts that can search a btrfs filesystem for dupes 
 and replace them with cp --reflink?

Nothing really working and tested very well. After I get to known the missing 
cp --reflink feature I stopped to develop the script any further.

I use btrfs for my backups. Ones a day I rsync --delete --inplace the complete 
system to a subvolume, snapshot it, delete some tempfiles in the snapshot.
In addition to that I wanted to shrink file-duplicates.

What the script should do:
1. I md5sum every file
2. If the checksums are identical, I compare the files
3. If 2 or more files are really identical:
   - move one to a temp-dir
   - cp --reflink the second to the position and name of the first
   - do a chown --reference, chmod --reference and touch --reference
 to copy owner, file mode bits and time from the orginal to the
 reflink-copy and then delete the original in temp-dir

Everything could be done with bash. Thinkable is the use of a database for the 
md5sums, which could be used for other purposes in the future.
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: cross-subvolume cp --reflink

[Konstantinos Skarlatos]

On Κυριακή, 1 Απρίλιος 2012 8:07:54 μμ, Norbert Scheibner wrote:

On: Sun, 01 Apr 2012 19:45:13 +0300 Konstantinos Skarlatos wrote



That's my point. This poor man's dedupe would solve my problems here

very well. I don't need a zfs-variant of dedupe. I can implement such a
file-based dedupe with userland tools and would be happy.

do you have any scripts that can search a btrfs filesystem for dupes
and replace them with cp --reflink?


Nothing really working and tested very well. After I get to known the missing 
cp --reflink feature I stopped to develop the script any further.

I use btrfs for my backups. Ones a day I rsync --delete --inplace the complete 
system to a subvolume, snapshot it, delete some tempfiles in the snapshot.


In my setup I rsync --inplace many servers and workstations, 4-6 times 
a day into a 12TB btrfs volume, each one in its own subvolume. After 
every backup a new ro snapshot is created.


I have many cross-subvolume duplicate files (OS files, programs, many 
huge media files that are copied locally from the servers to the 
workstations etc), so a good dedupe script could save lots of space, 
and allow me to keep snapshots for much longer.




In addition to that I wanted to shrink file-duplicates.

What the script should do:
1. I md5sum every file
2. If the checksums are identical, I compare the files
3. If 2 or more files are really identical:
- move one to a temp-dir
- cp --reflink the second to the position and name of the first
- do a chown --reference, chmod --reference and touch --reference
  to copy owner, file mode bits and time from the orginal to the
  reflink-copy and then delete the original in temp-dir

Everything could be done with bash. Thinkable is the use of a database for the 
md5sums, which could be used for other purposes in the future.



--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: cross-subvolume cp --reflink

[Norbert Scheibner]

 On: Sun, 01 Apr 2012 19:22:42 +0200Klaus A. Kreil wrote

 I am just an interested reader on the btrfs list and so far have never 
 posted or sent a message to the list, but I do have a dedup bash script 
 that searches for duplicates underneath a directory (provided as an 
 argument) and hard links identical files.
 
 It works very well for an ext3 filesystem, but I guess the basics should 
 be the same for a btrfs filesystem.

Everyone feel free to correct me here, but:
At the moment there is a little problem with the maximum number of hard links 
in a directory. So I wouldn't use them wherever possible to avoid any thinkable 
problems in the near future.

Plus to hard link 2 files means, that change one file You change the other one. 
It's something You either don't want to happen or something, which could be 
done in better ways. The cp --reflink method on a COW-fs is a much smarter 
method.

Plus hard links across subvolumes do match the case of hard links across 
devices on a traditional fs, which is forbidden.

Plus hard links In my opinion should really be substituted by soft links, 
because hard links are not transparent at the first sight and can not be copied 
as it.

So no, I'd rather want the patch to allow cross-subvolume cp --reflink in the 
kernel and I will wait for that to happen.

Greetings
   Norbert
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: cross-subvolume cp --reflink

[Konstantinos Skarlatos]

On 1/4/2012 9:39 μμ, Norbert Scheibner wrote:

On: Sun, 01 Apr 2012 19:22:42 +0200Klaus A. Kreil wrote



I am just an interested reader on the btrfs list and so far have never
posted or sent a message to the list, but I do have a dedup bash script
that searches for duplicates underneath a directory (provided as an
argument) and hard links identical files.

It works very well for an ext3 filesystem, but I guess the basics should
be the same for a btrfs filesystem.

Thanks for the nice script, it works fine here!
I just added a du -sh $1 line at the beginning and end to see how much 
space it saves.


Everyone feel free to correct me here, but:
At the moment there is a little problem with the maximum number of hard links 
in a directory. So I wouldn't use them wherever possible to avoid any thinkable 
problems in the near future.

Plus to hard link 2 files means, that change one file You change the other one. 
It's something You either don't want to happen or something, which could be 
done in better ways. The cp --reflink method on a COW-fs is a much smarter 
method.
thats true, cp --reflink is much better. Also am I wrong that btrfs has 
a limitation on the number of hard links that can only be fixed with a 
disk format change?


Plus hard links across subvolumes do match the case of hard links across 
devices on a traditional fs, which is forbidden.

Plus hard links In my opinion should really be substituted by soft links, 
because hard links are not transparent at the first sight and can not be copied 
as it.

So no, I'd rather want the patch to allow cross-subvolume cp --reflink in the 
kernel and I will wait for that to happen.

Greetings
Norbert


--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: cross-subvolume cp --reflink

[Konstantinos Skarlatos]

On 1/4/2012 9:11 μμ, Norbert Scheibner wrote:

On: Sun, 01 Apr 2012 20:19:24 +0300 Konstantinos Skarlatos wrote



I use btrfs for my backups. Ones a day I rsync --delete --inplace
the

complete system to a subvolume, snapshot it, delete some tempfiles
in the snapshot.

In my setup I rsync --inplace many servers and workstations, 4-6
times a day into a 12TB btrfs volume, each one in its own
subvolume. After every backup a new ro snapshot is created.

I have many cross-subvolume duplicate files (OS files, programs,
many huge media files that are copied locally from the servers to
the workstations etc), so a good dedupe script could save lots of
space, and allow me to keep snapshots for much longer.


So the script should be optimized not to try to deduplicate the whole
fs everytime but the newly written ones. You could take such a file
list out of the rsync output or the btrfs subvolume find-new
command.


a cron task with btrfs subvolume find-new would be ideal i think

Albeit the reflink patch, You could use such a bash-script inside one
subvolume, after the rsync and before the snapshot. I don't know how
much space it saves for You in this situation, but it's worth a try
and a good way to develop such a script, because before You write
anything to disc You can see how many duplicates are there and how
much space could be freed.

MfG Norbert


--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html