On Wed, 18 Nov 2009, Karel Zak wrote: > It's kernel who cares about M_REMOUNT & MS_BIND. And kernel > MS_REMOUNT behavior was silently changed one year ago. Yeah, that's an ABI breakage. Luckily nobody seemed to care, so everything is fine :) > The mount(8) command has exactly defined way how works with mount > options for many years. There is not any exception for MS_BIND. It > reads options from fstab/mtab and apply options from command line, > the result is send to kernel. That's debatable, MS_BIND is not a mount option, it's a mount *action*. Just like MS_REMOUNT. So the way mount(8) handles MS_BIND is rather inconsistent. > I think the current (undocumented:-) kernel behavior is not clear. CC-ing Michael Kerrisk. Michael, could you please add an explanation of (MS_REMOUNT & MS_BIND) to the mount(2) man page? When these flags are used together, they change the per-mount flags (6-th field in /proc/self/mountinfo), not the per-superblock flags (last field in /proc/self/mountinfo). > We use two options for three separate operations: MS_REMOUNT (remount > superblock), MS_BIND (loopback) and MS_REMOUNT & MS_BIND (change mnt > flags). The mount(2) API is a big mess... > > It would be much cleaner to have a mount option, say > > --change-mnt-flags, that is equivalent to "--bind -oremount". > > Maybe, the question is how many users already depend on mount --bind > /old /new; mount -o remount,ro /new. I have no idea. I just know that the current behavior is inconsistent and constraining. And it won't help migrating mount(8) off of /etc/mtab. Thanks, Miklos -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
