From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Lennart Sorensen <lsorense@csclub.uwaterloo.ca>
Cc: Andreas Dilger <adilger.kernel@dilger.ca>,
linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: ext4 ignoring rootfs default mount options
Date: Wed, 7 Mar 2018 17:50:43 -0500 [thread overview]
Message-ID: <20180307225043.GA15217@thunk.org> (raw)
In-Reply-To: <20180307191324.qtloesy4zdlkfnwv@csclub.uwaterloo.ca>
On Wed, Mar 07, 2018 at 02:13:24PM -0500, Lennart Sorensen wrote:
>
> Trying to use tune2fs -E mount_opts to set some default options, and
> can't figure out how to enter two options at once.
>
> ...
>
> Sure in this case I can set one with -o and the other with -E, but in
> general there seems to be a small problem here, probably only in user
> space though. Seems tune2fs needs some change in how it deals with
> extended options that contain commas.
Yes, this is a shortcoming in tune2fs. You can set extended mount
options using debugfs:
debugfs -w -R "set_super_value mount_opts foo,bar" /dev/sda1
... but there ought to be some way to support some kind of quoting
mechanism so that tune2fs can understand when a comma is part of an
extended option value, as opposed to separating extended options.
Extended options haven't been used much, so it's not been something
that has gotten a lot of polish. Backing up for a bit, is there a
reason why you need so many mount options when mounting the root file
sytsem? Specifically, why do you want to turn off dellayed allocation?
- Ted
next prev parent reply other threads:[~2018-03-07 22:50 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-06 19:03 ext4 ignoring rootfs default mount options Lennart Sorensen
2018-03-07 4:06 ` Theodore Y. Ts'o
2018-03-07 15:14 ` Lennart Sorensen
2018-03-07 16:08 ` Theodore Y. Ts'o
2018-03-07 16:15 ` Lennart Sorensen
2018-03-07 19:13 ` Lennart Sorensen
2018-03-07 22:23 ` Tyson Nottingham
2018-03-07 22:50 ` Theodore Y. Ts'o [this message]
2018-03-15 18:35 ` Lennart Sorensen
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=20180307225043.GA15217@thunk.org \
--to=tytso@mit.edu \
--cc=adilger.kernel@dilger.ca \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lsorense@csclub.uwaterloo.ca \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.