A question for Linux hackers...

On my file server, I have several logical partitions, one of which holds all of my media. This partition is mounted at /mnt/media, but for simplicity, I've added some bind mounts under / to make my paths shorter. Here are the relevant lines in my fstab:



I was using symbolic links instead of bind mounts before, but was having problems traversing them properly from CIFS clients. I think I figured out the smb.conf magic to solve most of those problems, but in that process, discovered bind mounts, and figured they were a better fit for my setup.

The problem I'm having now is that moving files between these bind mounted partitions is slow. For example, say I'm in /incoming ("real" path /mnt/media/incoming) and I want to move a file to /video ("real" path /mnt/media/video). In reality, this is a move on the same partition, and should be instantaneous. However, when I do this, it takes a long time, because the system is clearly copying the entire file. In fact, if I cd to /mnt/media/incoming/video and do a "mv file ../video", the move is instantaneous, as expected.

I think what's happening is that the system doesn't realize that the source and destination mounts are actually on the same partition. So, why not?

The problem you're having right is you have set this up to make one filesystem look like some separate ones.

But that of course means the system then thinks they really are different i.e. it will run separate file system instances then won't it? I assume that's the basically the answer to your "why not"?

Can't have the best of both worlds maybe?

It must be somewhere in between (one fs and two) though since really it's a single file system that needs to be kept in sync.

Sorry don't have an answer for you.

Mmmm.. I think I would call that a bug, because clearly it should work as you expected it to.

EDIT: Most likely a bug in whatever program you're using to move the files around.
It should try to use link(2) first, and then fall back on a file copy if that fails.

You might be able to use strace on the command to see what it is doing.


Cheers

Oh, wait. It's a kernel deficiency. From the link(2) manpage:

Linux permits a filesystem to be mounted at multiple points,
but link(2) does not work across different mount points,
even if the same filesystem is mounted on both.

So that's a shortcoming of the link(2) system call on Linux.

Cheers

Ah, okay. Oddly, the man page on my system doesn't have that caveat listed. For the EXDEV error, it just says "oldpath and newpath are not on the same filesystem."

I guess I'll try switching back to symlinks instead of bind mounts.

If you want to be able to do this, here (attached) is a simple kernel patch that I just now cooked up to allow it. It seems to work under light testing here on my own machine.

I'm also posting to LKML to find out more from the filesystem gurus.

Cheers

Mark, you are amazing!
Wow.

And thus we see the advantages of a) Linux and b) being acquainted with the Linux IDE Guy.

The answer from the filesystem gurus, is that the restriction is (1) artificial, and (2) deliberate. It's there to enable a way to impose extra security on a multi-user system.

But for a single-user system (single regular user, "you", plus the superuser "root"), there's no need. So the patch I posted ought to be safe for your own machines.

Cheers

..and here (attached) is the simplified version of the patch, without the "printk" (kernel log) line and associated logic.

Cheers

Yeah, I saw the response on LKML. Thanks for looking into it. I don't think I'm going to want to have to recompile the kernel with each new version, so I think I'll just go path of least resistance and change the bind mounts back to symlinks.

Well, opensource

I was futzing around on my pictureframe on friday and couldn't get X to start without a cursor. A quick 'apt-get source', an irc chat and a few minutes (about an hour actually) and Xorg will have a -nocursor option in the next release - *so* cool.

Thank you!
I will also find that very useful. (And for the same reasons.)