Re: reflink utils

Karel Zak <[email protected]> Mon, 3 Nov 2025 14:36:43 +0100
Newsgroups org.kernel.vger.util-linux
Message-ID <4j4s35hqascwnb7hvpg7ony7eia6qabvu3qegwjgi6faisnpm4@y62d6gxpzciu>
 Hi Dick,

On Sat, Nov 01, 2025 at 09:42:59AM +0100, Dick Marinus wrote:
> I've created some tools to work with reflinks (FICLONERANGE) which I'd
> like to include in the util-linux project.
> 
> Reflinks can be used to share equal blocks between files. Cloning a
> block using reflinks will not copy any data saving I/O and disk wear/
> space.

Yes, we already support "hardlink --reflink" for this purpose.

> First tool is blkdiff which takes two files, a base file and a new file. 
> Then it creates both a delta file and an index, the delta file contains
> the different blocks in new file compared to the base file and an index
> file which contains the block indexes in either the base file or the
> delta file so the new file can be constructed from that.
> 
> This is a bit similar to rdiff from librsync but uses fixed block sizes
> and doesn't require the chunks to be in the same order. FICLONERANGE
> only allows you to clone blocks of the filesystems block size.
> 
> The next tool is blkpatch which uses the base, index and delta file to
> construct new file using reflinks.
> 
> I've also created blkcat which concatenates the blocks from all supplied
> files using reflinks into a single file with the idea to use this as a
> basefile to deduplicate files on a filesystem.
> 
> I think reflinks, or at least FICLONERANGE is linux specific so
> util-linux would be a good fit. Reflinks are currently supported (AFAIK)
> for BtrFS and XFS.
> 
> I'd love to know:
> 
> - can/should I contribute these to util-linux?

The first thing I always ask is if the functionality can be added to
an existing tool. In your case, the idea is so original that I don't
see anything we can integrate it into.

> - are blkdiff, blkpatch and blkcat good names?

The "blk" prefix makes it seem like it's for block devices instead of files.

How about following the ioctl name and using one tool that supports
more commands, like:

  ficlone diff
  ficlone patch
  ficlone cat

The issue is that users might not be familiar with ioctl, so "ficlone"
might not appeal to them. 

Perhaps use "reflink" as a name. Then you will have a generic tool,
and you can add features like "reflink copy" or "reflink status," etc.

> - what's required more? I can image I need to add some man pages etc.

Yes, man pages, bash-completion scripts, and ideally some tests, but
don't waste time on man pages, etc., before the code is ready to
merge.

> I already found the Documentation/howto-contribute.txt which I would
> use to contribute these utilities. GPL-2 is fine with me.

It's best to create a draft pull request on GitHub so we can all play
with it, review it, etc.

    Karel

-- 
 Karel Zak  <[email protected]>
 http://karelzak.blogspot.com