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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Κυριακή, 1 Απρίλιος 2012 6:27:49 μμ, Norbert Scheibner wrote:> 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? >+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"> 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 majordomo@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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, Apr 1, 2012 at 11:27 AM, Norbert Scheibner <scno@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? -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Κυριακή, 1 Απρίλιος 2012 7:41:36 μμ, Norbert Scheibner wrote:>> 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.do you have any scripts that can search a btrfs filesystem for dupes and replace them with cp --reflink?> > 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> 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. 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> On: Sun, 01 Apr 2012 19:22:42 +0200"Klaus 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 1/4/2012 9:39 μμ, Norbert Scheibner wrote:>> On: Sun, 01 Apr 2012 19:22:42 +0200"Klaus 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 <scno@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
Am 29.04.2012, 01:53 Uhr, schrieb Hubert Kario <hka@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 <scno@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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 <scno@gmx.net> wrote:> Am 29.04.2012, 01:53 Uhr, schrieb Hubert Kario <hka@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 <scno@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 majordomo@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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 <scno@gmx.net> wrote: > > Am 29.04.2012, 01:53 Uhr, schrieb Hubert Kario <hka@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 <scno@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 majordomo@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 majordomo@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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Aug 17, 2012 at 12:20 AM, Marc MERLIN <marc@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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, Aug 19, 2012 at 12:08:01AM -0500, Mitch Harder wrote:> On Fri, Aug 17, 2012 at 12:20 AM, Marc MERLIN <marc@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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Aug 16, 2012 at 5:41 PM, james northrup <northrup.james@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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Aug 20, 2012 at 11:08 AM, Jérôme Poulin <jeromepoulin@gmail.com> wrote:> > On Thu, Aug 16, 2012 at 5:41 PM, james northrup > <northrup.james@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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html