Re: Cross-subvolume rename behavior

[Sean Greenslade <sean@seangreenslade.com>]

On Thu, Mar 23, 2017 at 07:23:40AM -0400, Austin S. Hemmelgarn wrote:
> On 2017-03-23 06:09, Hugo Mills wrote:
> >    Direct rename (using rename(2)) isn't possible across subvols,
> > which is what the EXDEV result indicates. The solution is exactly what
> > mv does, which is reflink-and-delete (which is cheaper than
> > copy-and-delete, because no data is moved). In theory, you probably
> > could implement rename across subvolumes in the FS, but it would just
> > be moving the exact same operations from userspace to kernel space.
> >
> Doing so though would have the advantage that it theoretically could be made
> (almost) atomic like a normal rename is, whereas the fallback in mv is
> absolutely not atomic.
> > 
> >    I think that the solution here is for the sshfs stack to be fixed
> > so that it passes the EXDEV up to the mv command properly, and passes
> > the subsequent server-side copy (reflink) back down correctly.
> 
> This would be wonderful in theory, but it can't pass down the reflink,
> because the SFTP protocol (which is what sshfs uses) doesn't even have the
> concept of reflinks, so implementing this completely would require a
> revision to the SFTP protocol, which I don't see as likely to happen.

Thanks for the insights, Hugo and Austin. That's more or less what I was
expecting, so I guess my next stop will be with the openssh folks.
Though I was looking over the SFTP protocol, and none of the SSH_FX_*
errors seem suitable for this purpose. This might require a workaround
in sshfs...

--Sean