From: Niels de Vos <ndevos@redhat.com>
To: Karel Zak <kzak@redhat.com>
Cc: util-linux@vger.kernel.org
Subject: Re: [RFC] mount: overwrite options from /etc/fstab when given on the commandline
Date: Wed, 01 Aug 2012 12:11:00 +0200 [thread overview]
Message-ID: <501900B4.9040604@redhat.com> (raw)
In-Reply-To: <20120801094833.GC1019@x2.net.home>
On 08/01/2012 11:48 AM, Karel Zak wrote:
> On Wed, Aug 01, 2012 at 11:11:41AM +0200, Niels de Vos wrote:
>> it seems that some of the options given in /etc/fstab are not overloaded by
>> options given on the mount-commandline.
>
> Well, all depends on kernel (and FS driver) how mount options are
> evaluated. We have no any strict rules for 'source' and 'mount
> options' in the mount(2) syscall.
>
> The generic convention (!= rule) is that the option overwrites an
> option previously specified in the mount options string:
>
> aaa=x,bbb,aaa=y -> aaa should be 'y'
>
> This is reason why mount(8) only appends the options from command line
> to the options string from fstab.
>
> Anyway, depends on FS driver how the options string will be
> interpreted -- for example btrfs supports duplicate device= mount
> option.
Ah, okay, if there are valid use-cases for options to be listed multiple
times, it won't be possible to overload the options from /etc/fstab by the
options from the commandline.
>> Some options are not allowed to be
>> passed multiple times (like the SElinux context options) and mounting will fail
>> if options are present in both /etc/fstab and on the commandline.
>
> This is stupid SELinux disadvantage and SELinux should be fixed.
Yeah, sounds like it. I may have a look on how the kernel can handle the
SElinux options better.
>> Is there a reason for not overloading the options from /etc/fstab by the
>> options given on the commandline?
>>
>> The patch below changes the behaviour of mount so that options on the
>> commandline replace options given in /etc/fstab.
>
> I'd like to avoid that mount(8) tries to understand filesystem specific
> options. The command mount(8) has no clue about the options (non-VFS
> options). For example:
>
> fstab:
> /dev/sda /mnt btrfs device=/dev/sdb 0 0
>
> command line:
>
> mount /mnt -o device=/dev/sdc,device=/dev/sdd
>
>
> so the final mount options string:
>
> device=/dev/sdb,device=/dev/sdc,device=/dev/sdd
>
> .. and this all is pretty valid for btrfs.
Nice example!
> I'd like to implement for the next release 2.23 a new command line
> options to specify a way how compose the final options string in the
> mount(8). It's already in our Documentation/TODO file, see
> --options-mode, probably something like:
>
> --options-mode={ignore,append,prepend,replace,dedup}
>
> or so.
Hmm, that sounds like it'll solve the problem, unless you'r combining
SElinux contexts and btrsf...
Thanks for your detailed response,
Niels
prev parent reply other threads:[~2012-08-01 10:11 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-01 9:11 [RFC] mount: overwrite options from /etc/fstab when given on the commandline Niels de Vos
2012-08-01 9:48 ` Karel Zak
2012-08-01 10:03 ` Karel Zak
2012-08-01 10:14 ` Niels de Vos
2012-08-01 10:32 ` Karel Zak
2012-08-01 11:58 ` Niels de Vos
2012-08-01 17:08 ` Karel Zak
2012-08-02 9:46 ` Niels de Vos
2012-08-01 10:11 ` Niels de Vos [this message]
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=501900B4.9040604@redhat.com \
--to=ndevos@redhat.com \
--cc=kzak@redhat.com \
--cc=util-linux@vger.kernel.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).