On 2017-03-23 06:09, Hugo Mills wrote:
On Wed, Mar 22, 2017 at 10:37:23PM -0700, Sean Greenslade wrote:
Hello, all. I'm currently tracking down the source of some strange
behavior in my setup. I recognize that this isn't strictly a btrfs
issue, but I figured I'd start at the bottom of the stack and work my
way up.
I have a server with a btrfs filesystem on it that I remotely access on
several systems via an sshfs mount. For the most part this works
perfectly, but I just discovered that moving files between subvolumes on
that mount fails with a confusing "Operation not permitted" error.
After doing some digging, it turns out it's not actually a permissions
error. If I do the same operation locally on the server, it succeeds,
but an strace of the mv reveals that the rename() syscall returns EXDEV.
The mv util takes this as a sign to fall back on the copy-and-delete
routine, so the move succeeds. Unfortunately, it seems that somewhere in
sshfs, sftp, or fuse, the EXDEV is getting turned into a generic
failure, which mv apparently interprets as "permission denied".
So my question for the btrfs devs: is rename()-ing across subvolumes
not feasible, or is this simply a case of no one has implemented that
yet?
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
