[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#25930: optimize mv for multiple bind mounts
From: |
L A Walsh |
Subject: |
bug#25930: optimize mv for multiple bind mounts |
Date: |
Thu, 02 Mar 2017 18:24:36 -0800 |
User-agent: |
Thunderbird |
Bernhard Voelker wrote:
On 03/02/2017 10:16 PM, L A Walsh wrote:
Anyone know why Linux doesn't do detection by device vs.
by mount point? Both pieces of info have their use, but for rename
seems that 'by device' would be optimal.
quick guess: because not only the device matters. What if e.g. the
other bind mount is read-only?
---
Not "cleanly" supported. mount man page:
Note that the filesystem mount options will remain the same as
those on the original mount point, and cannot be changed by
passing the -o option along with --bind/--rbind. The mount
options can be changed by a separate remount command, for exam-
ple:
mount --bind olddir newdir
mount -o remount,ro newdir
Note that the behavior of the remount operation depends on the
/etc/mtab file. The first command stores the 'bind' flag in the
/etc/mtab file and the second command reads the flag from the
file. If you have a system without the /etc/mtab file or if you
explicitly define source and target for the remount command
(then mount(8) does not read /etc/mtab), then you have to use
the bind flag (or option) for the remount command too. For
example:
mount --bind olddir newdir
mount -o remount,ro,bind olddir newdir
Note that remount,ro,bind will create a read-only mountpoint
(VFS entry), but the original filesystem superblock will still
be writable, meaning that the olddir will be writable, but the
newdir will be read-only.
----
It's a bit bothersome that the behavior of the remount
is dependent on existence of /etc/mtab, contents and mount order.
Interestingly, though, on Windows, I haven't found
any way of mounting a file system "Read-Only", so maybe that's
not something Windows normally has to worry about in moving files.