btrfs-progs icon indicating copy to clipboard operation
btrfs-progs copied to clipboard

Add reflink/clone command

Open kdave opened this issue 4 years ago • 4 comments

Add a command eg. btrfs fi reflink (name can be finalized later) that would:

  • in the simplest form do a reflink from file A to B (possibly honoring the fileattrs like NOCOW)
  • allow to specify the source range and target offset of clone

To be decided:

  • multiple files on one command line, eg. multiple sources into one target (N:1), or multiple targets (N:N), or with 1:N for completeness
  • exact syntax, maybe positional arguments so we could have something like --source file1 1 --start 0 --length 4K --target file2 --offset 8K
  • commands proccessed in order so names can be repeated and later commands would be affected by effects of previous commands (like clone 0-4K to 4K, then clone 0-8K to 8K etc, or maybe it's too crazy)

kdave avatar Aug 31 '21 15:08 kdave

Would it be like "cp --reflink" command? plus it can set range?

realwakka avatar Aug 31 '21 15:08 realwakka

Yes, plus it should transparently reflink nocow->nocow file unlike cp.

kdave avatar Aug 31 '21 15:08 kdave

Thanks, It should also copy source's fileattr. IMHO, N:N would be so complicated to use it and it would be hard to represent each range of targets and sources in command line. Maybe it needs some json format for input?

And this command would use ioctl like FICLONERANGE or FIDEDUPERANGE?

I don't know well but could I handle this? if it's okay.

realwakka avatar Aug 31 '21 16:08 realwakka

If you mean fileattr the extended attributes, then yes. Ideall be as close as possible to what would cp do plus the reflink.

Json for input is quite strange, this is supposed to be a command line interface to the clone ioctl. Yeah N:N is strange, we can skip it.

kdave avatar Aug 31 '21 17:08 kdave

I've pushed a stub of the reflink group to devel, feel free to continue, a pull request is OK. There's a sample command but does nothing, it's namely for the interface and syntax verification. Right now I'd go with a separate command group as there may be other command requests and so that we don't overload the 'filesystem' group.

kdave avatar Dec 07 '22 00:12 kdave