[cc'd xfs@xxxxxxxxxxx] Side effect of this commit: http://oss.sgi.com/cgi-bin/gitweb.cgi?p=xfs/xfs-2.6.git;a=commit;h=0327f9d799ebb96f67c80dd732b1fdb09527365e Christoph? FWIW, noikeep is the default,
I'ts most likely a fallout, but I wonder why. To get this behaviour moutn would have to add all the options it finds in /proc/self/mounts to the command line. Added the util-linux-ng list to shed som
mount(8) does not read and use /proc/self/mounts at all. Karel Man mount: remount Attempt to remount an already-mounted file system. This is commonly used to change the mount flags for a file system,
So, given the command at issue was: luna ~ # mount -o remount,rw /usr We're seeing the second case where mount is merging all the options in /etc/fstab into the options passed into the remount comman
(forgive me, I'm an XFS user, not an XFS developer, so this might be ignorant) The filesystem presumably knows what options it was originally mounted with. Thus if you take the difference of the set
Sure. But that does not answer my question about what to do with options that can't be changed. Options can come from more than just /etc/fstab - they can come from the mount command line itself as e
How about a middle ground: ignore, but not silently? Report an error, or send it to the syslog, or both, but ultimately ignore unchangeable options, change what can be changed, and give the user/admi
I think the idea is to behave the same as other FS do, not to innovate. FWIW, your root filesystem does not need to be rw. I keep mine ro nearly all the time on my laptop, only mounting rw if I need
[cc'd xfs@xxxxxxxxxxx] Side effect of this commit: http://oss.sgi.com/cgi-bin/gitweb.cgi?p=xfs/xfs-2.6.git;a=commit;h=0327f9d799ebb96f67c80dd732b1fdb09527365e Christoph? FWIW, noikeep is the default,
I'ts most likely a fallout, but I wonder why. To get this behaviour moutn would have to add all the options it finds in /proc/self/mounts to the command line. Added the util-linux-ng list to shed som
mount(8) does not read and use /proc/self/mounts at all. Karel Man mount: remount Attempt to remount an already-mounted file system. This is commonly used to change the mount flags for a file system,
So, given the command at issue was: luna ~ # mount -o remount,rw /usr We're seeing the second case where mount is merging all the options in /etc/fstab into the options passed into the remount comman
(forgive me, I'm an XFS user, not an XFS developer, so this might be ignorant) The filesystem presumably knows what options it was originally mounted with. Thus if you take the difference of the set
Sure. But that does not answer my question about what to do with options that can't be changed. Options can come from more than just /etc/fstab - they can come from the mount command line itself as e
How about a middle ground: ignore, but not silently? Report an error, or send it to the syslog, or both, but ultimately ignore unchangeable options, change what can be changed, and give the user/admi
I think the idea is to behave the same as other FS do, not to innovate. FWIW, your root filesystem does not need to be rw. I keep mine ro nearly all the time on my laptop, only mounting rw if I need
[cc'd xfs@xxxxxxxxxxx] Side effect of this commit: http://oss.sgi.com/cgi-bin/gitweb.cgi?p=xfs/xfs-2.6.git;a=commit;h=0327f9d799ebb96f67c80dd732b1fdb09527365e Christoph? FWIW, noikeep is the default,
I'ts most likely a fallout, but I wonder why. To get this behaviour moutn would have to add all the options it finds in /proc/self/mounts to the command line. Added the util-linux-ng list to shed som
mount(8) does not read and use /proc/self/mounts at all. Karel Man mount: remount Attempt to remount an already-mounted file system. This is commonly used to change the mount flags for a file system,
So, given the command at issue was: luna ~ # mount -o remount,rw /usr We're seeing the second case where mount is merging all the options in /etc/fstab into the options passed into the remount comman