9

If I mount --bind /a in /b and if I mv /a/bigfile /b/ it will take a lot of time (if the source file is big). This will actually copy the file and then delete the source file instead of simply updating the filesystem's file table.

I understand how and why mount --bind works. As pointed out by others, there are some good explanations on that:

Is there any way of telling mount that a mount --bind is in the same filesystem so that operations like this (move) are done by actually updating the filesystem's file table?

I'm asking how to solve this problem and not how to understand it: maybe a kernel patch already available that I'm not aware of it or a missing parameter I didn't find already (etc).

Why: In my current setup there is a service (nextcloud) that only supports the mount --bind. I can't use symlinks. If I need to, say, have a shared folder inside each account of nextcloud it must be with bind. I may accept any solution that works with nextcloud if it is made in the filesystem/kernel level. This is because the current setup also includes access to these files in other ways, like ssh. In other words, I would like be able to move a file as in example using any command or application.

Étienne
  • 135
Noeljunior
  • 326

3 Answers3

10

Apparently not, the man page rename(2) mentions this:

EXDEV oldpath and newpath are not on the same mounted filesystem. (Linux permits a filesystem to be mounted at multiple points, but rename() does not work across different mount points, even if the same filesystem is mounted on both.

If I recall correctly, a bind mount is the same as just mounting the same filesystem multiple times, i.e. there's no "source" and "target" for the bind after the fact.

There's also another answer to another question on the same subject from a couple of months ago. That one has pointers to a discussion about it with the kernel developers. So go upvote that.

ilkkachu
  • 138,973
  • 2
    Unfortunately this seems to be the right answer. Mount bind is not like mounting the same filesystem multiple though it may look like that. – Noeljunior Nov 22 '17 at 23:32
  • 1
    To the edit: again, I'm aware of the problem. I'm asking if there is a solution at that level I ask. A solution may be a patch or a parameter. The behavior of the mount --bind may be like it is but doesn't mean that there is no alternatives. – Noeljunior Nov 23 '17 at 12:54
  • @Noeljunior, ok, fine. It should be possible by fixing the kernel to do it. – ilkkachu Nov 23 '17 at 14:05
  • @Noeljunior, as for bind mounts vs. repeat mounting, a bind mount is not dependent on the origin, i.e. you can do mount $dev /tmppath; mount --bind /tmppath/subdir /otherpath; umount /tmppath and it works fine. Also, if you look at the output of findmnt after a bind mount, it appears as a distinct mount of the same device. So at least it seems quite similar to a repeat mount, though of course you're free to correct me if you know the details more closely. – ilkkachu Nov 23 '17 at 14:07
0

i have the same problem with nextcloud and samba in docker containers. i solved it by moving all data inside nextcloud and let others bind mount them from this volume.

so from any services point of view a mv is always inside only one bind mount.

not sure if this helps you though

Florian Werner
  • 1
-1

Using rsync instead mv should solve the issue. Try using the following command

rsync -avP /a/bigfile /b/bigfile

The issue is because the viewpoint of mount --bind is in kernel and is hidden from higher level programs like mv. Unlike mv, rsync moves the modified parts of a file only.

This explains about mount --bind What is a bind mount?

Abhik Bose
  • 2,118
  • Ok, nice alternative. Maybe I was not clear enough about the limitations. I understand the problem and what is a mount --bind. The thing is that there are a lot of users using nextcloud, ssh mounted drivers, samba etc. When I say I like to solve the problem at the kernel/filesystem level is because I can't control which tools does nextcloud or sshfs uses to move files. I would like that moving the /a/bigfile to /b/bigfile be fast everywhere (nextcloud, sshfs, samba, etc). – Noeljunior Nov 22 '17 at 18:54
  • 1
    Sorry, I'm downvoting this because from my tests it didn't look like using rsync is any faster than using mv. Specifically, I tried moving a file from a bind mount to a folder on the same underlying filesystem, and rsync, just like mv, was not able to move the file instantly (and it's in fact 3 times slower than mv, probably because of its overhead) – a3nm Jan 14 '19 at 00:48