From: Jerome Marchand <jmarchan-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: util-linux-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Linux Kernel Mailing List
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: [RFC] fs: filesystem specific options and remount
Date: Fri, 03 Feb 2012 16:22:23 +0100 [thread overview]
Message-ID: <4F2BFBAF.5020703@redhat.com> (raw)
When remounted without option specified, some filesystems keep the
options that are already set (e.g. procfs, fat) and some reset them to
default (e.g. devpts).
Regarding options that are specified at remount, behavior of
filesystems also differ: some apply them (procfs, devpts), some
silently disregard them (e.g. fat) and some have a more elaborate
behavior (e.g. xfs apparently allows a subset of options to be changed
and issues warning if someone tries to change any other option).
Is there any policy regarding what the correct behavior should be?
This variety of behaviors tends to confuse mount utility which often
does not show the correct option actually set after a remount and
most certainly confuses the users as well.
Here is a example of discrepancy between mount (/etc/mtab) and
/proc/mounts:
$ grep proc /proc/mounts
/proc /proc proc rw,relatime 0 0
$ mount | grep proc
proc on /proc type proc (rw)
$ mount -o remount,hidepid=2 /proc/
$ grep proc /proc/mounts
/proc /proc proc rw,relatime,hidepid=2 0 0
$ mount | grep proc
proc on /proc type proc (rw,hidepid=2)
$ mount -o remount /proc/
$ grep proc /proc/mounts
/proc /proc proc rw,relatime,hidepid=2 0 0
$ mount | grep proc
proc on /proc type proc (rw)
And here is the discrepancy: mount does not show "hidepid=2" option
that is actually still set and enforced. Note that mount also missed
the relatime option to begin with.
Regards,
Jerome
--
To unsubscribe from this list: send the line "unsubscribe util-linux" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next reply other threads:[~2012-02-03 15:22 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-03 15:22 Jerome Marchand [this message]
2012-02-06 22:41 ` [RFC] fs: filesystem specific options and remount Jan Kara
[not found] ` <20120206224116.GE24840-+0h/O2h83AeN3ZZ/Hiejyg@public.gmane.org>
2012-02-06 23:08 ` Karel Zak
2012-02-10 17:08 ` Phillip Susi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F2BFBAF.5020703@redhat.com \
--to=jmarchan-h+wxahxf7alqt0dzr+alfa@public.gmane.org \
--cc=linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=util-linux-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).