Re: Supporting reflinked/cow files in coreutils

[Philipp Thomas]

[Quoting in nearly full as to give Jeff enough context]

On Fri, 05 Oct 2012 18:20:57 +0200, <address@hidden> wrote:

>Glancing through the patch in the first message,
>
>    http://oss.oracle.com/pipermail/ocfs2-devel/2010-September/007293.html
>
>I have a hard time justifying the addition of so much code for a
>relatively small feature that will be useful only for OCFS2 file systems:
>
>  coreutils-6.9/src/du.c |  479 
> +++++++++++++++++++++++++++++++++++++++++++++++-
>  1 files changed, 473 insertions(+), 6 deletions(-)
>
>That's a lot of new always-compiled code that will be used only by a
>very small fraction of users.  And to add insult to injury, it extends
>the ugly tentacles of FIEMAP into du.c.  It was bad enough to have to
>use it in copy.c, and we're all impatient for something better, but
>SEEK_HOLE and SEEK_DATA aren't yet widely available.
>
>That's a lot of new code, not even counting these:
>
>  * lib/rbtree.c: Source file of rbtree.
>  * lib/rbtree.h: Header file of rbtree.
>  * lib/Makefile.am (libcoreutils_a_SOURCES): Add both of them.
>  ---
>   coreutils-6.9/lib/Makefile.am |    3 +-
>   coreutils-6.9/lib/Makefile.in |    4 +-
>   coreutils-6.9/lib/rbtree.c    |  403 
> +++++++++++++++++++++++++++++++++++++++++
>   coreutils-6.9/lib/rbtree.h    |  143 +++++++++++++++
>   4 files changed, 550 insertions(+), 3 deletions(-)
>
>Besides which, there is no reason to add new rbtree.[ch] code
>when there is already plenty of rbtree code in gnulib.
>
>If it can be made to work cleanly with BTRFS as well, and preferably
>*without* FIEMAP (if possible, though I fear that FIEMAP is the only
>interface we have for now), that would be even better.

I'd agree with you that It'd be much better if it would work with
OCFS2 and BTRFS.

>If you and/or Jeff are motivated enough, a good first step would be to
>post a rebased patch to bug-coreutils, preferably after you've switched
>out that rbtree.[ch] for gnulib's code.  I hesitate even to suggest
>that you rebase, because we might end up deciding it's not yet worth
>the cost, but let's hear what others have to say.  Maybe enough people
>use du and are bothered because the space used by their reflinked files
>is over-reported.

Jeff wrote last year that he'd post a rebased patch but hasn't done so
in the year that's passed. Maybe he will come forth and even use the
gnulib rbtree code.

>A final question: why use an rbtree rather than a hash table?
>du is already using hash tables at the required scale, and new code
>would be required at all.

That's up to Jeff to answer as I have nothing to do (yet) with that
code. I'm only an interested person who'd like such support in du.

Philipp