Re: [PATCH] mv: add --reflink to affect fallback copy

[David Sterba]

Hi,

sorry for late reply.

On Tue, Sep 02, 2014 at 05:20:36PM +0100, Pádraig Brady wrote:
> cp doesn't default to --reflink=auto as that would break the case where one 
> uses copy
> for durability reasons to have a second copy of the data.  Also for 
> performance reasons
> you may want the writes to happen at copy time rather than some latency 
> sensitive process
> working on a CoW file and being delayed by the writes possibly to a different 
> part of a mechanical disk.

I agree with that, the current default is good enough.

Some people suggested that it would be nice to have an environment
variable that would define the default cp --reflink behaviour. I don't
know if this is a common practice within coreutils, as it has a
potential to cause confusion. On the other hand allows to change the
default in a way that does not break everybody else systems.

However, this is getting out of the scope of the patch.

> This is not the case with mv though, so we might just --reflink=auto by 
> default?

That's a good idea and I follows the current 'mv' behaviour.  The
automatic reflink is between the "simple rename" or "fallback to full
copy", when the filesystem allows to do a faster copy. I don't see any
usability surprises here.

> I.E. not have an option. This would preclude allowing to avoid a standard 
> copy,
> but I'm not sure that's generally required.

Thinking about that, I don't see a problem here either. If the user
wants to do a copy, the 'mv' is not the tool of choice. The set of
possible reflink values would be 'auto' (default), or 'never'. And I
don't see the usecase for 'never' so looks safe to drop the option
completely.

> BTW should BTRFS handle the rename() transparently here?
> I.E. it could do the reflinking implicitly, if mv could do it?

I don't think it should. The simple rename only changes a few pointers
in the metadata structures. The reflink needs to create a new file, COW
all the extents.

This is much "heavier" operation compared to the simple rename and I'd
rather not do it in the kernel module. This gives more flexibility and
control to the userspace eg. in case of error handling.

I'll send an updated patch.