I'd like to set noatime as a default mount option for a filesystem:
# tune2fs -o noatime /dev/sdb1
tune2fs 1.42.9 (4-Feb-2014)
Invalid mount option set: noatime
Is there a reason why noatime can't be set as a default mount option?
Thinking of all these USB connected devices where it would be handy.
--
Tomasz Chmielewski
http://www.sslrack.com
On 8/28/14, 5:12 PM, Tomasz Chmielewski wrote:
> I'd like to set noatime as a default mount option for a filesystem:
>
> # tune2fs -o noatime /dev/sdb1
> tune2fs 1.42.9 (4-Feb-2014)
> Invalid mount option set: noatime
Right, the manpage doesn't list that as supported under "-o".
> Is there a reason why noatime can't be set as a default mount option? Thinking of all these USB connected devices where it would be handy.
I haven't looked, but I'm guessing it's because noatime is a vfs-level switch, and by the time the ext4 superblock is getting read and processed during mount, that chance has passed.
Just to keep things complicated and confusing ;) there's a different mechanism to do this as well:
# tune2fs -E mount_opts=noatime /dev/sdc1
which succeeds; however, this fails to be parsed at mount time:
[ 118.384020] EXT4-fs (sdc1): failed to parse options in superblock: noatime
for the same reasons, I guess. The documentation could certainly be better...
-Eric
On Fri, Aug 29, 2014 at 10:33:05AM -0500, Eric Sandeen wrote:
>
> > Is there a reason why noatime can't be set as a default mount option? Thinking of all these USB connected devices where it would be handy.
>
> I haven't looked, but I'm guessing it's because noatime is a
> vfs-level switch, and by the time the ext4 superblock is getting
> read and processed during mount, that chance has passed.
Yes, and this is also the cause of this user complaint/bug:
https://bugzilla.kernel.org/show_bug.cgi?id=61601
There was some discussion at the kernel summit by Andy Lutomirski to
create new mount system call with sane parsing, and Al Viro wasn't
totally against that idea. If we do go forward with some of the ideas
that was tossed about, this would be something else that would be a
nice thing to fix at the same time.
The whole distinction between VFS-level mount options (which are
parsed in userspace and passed down into the kernel using bits in a
bitfield) and file system-level mount options (which is parsed by the
kernel and passed in from userspace as a string) is just nasty.
What I would suggest is that all mount options would be passed all the
way down to the file system, and then there would be a library
function to handle common VFS-level mount options that would be called
by the file system's mount option handling code.
- Ted
P.S. At the kernel summit, Al recited the history of the mount system
call going all the way back to 1991-1992 when minix was the only file
system, and let's just say there is some major cruftiness going back
literally decades. :-/
On Fri, Aug 29, 2014 at 3:56 PM, Theodore Ts'o <[email protected]> wrote:
> On Fri, Aug 29, 2014 at 10:33:05AM -0500, Eric Sandeen wrote:
>>
>> > Is there a reason why noatime can't be set as a default mount option? Thinking of all these USB connected devices where it would be handy.
>>
>> I haven't looked, but I'm guessing it's because noatime is a
>> vfs-level switch, and by the time the ext4 superblock is getting
>> read and processed during mount, that chance has passed.
>
> Yes, and this is also the cause of this user complaint/bug:
>
> https://bugzilla.kernel.org/show_bug.cgi?id=61601
>
> There was some discussion at the kernel summit by Andy Lutomirski to
> create new mount system call with sane parsing, and Al Viro wasn't
> totally against that idea. If we do go forward with some of the ideas
> that was tossed about, this would be something else that would be a
> nice thing to fix at the same time.
>
> The whole distinction between VFS-level mount options (which are
> parsed in userspace and passed down into the kernel using bits in a
> bitfield) and file system-level mount options (which is parsed by the
> kernel and passed in from userspace as a string) is just nasty.
>
> What I would suggest is that all mount options would be passed all the
> way down to the file system, and then there would be a library
> function to handle common VFS-level mount options that would be called
> by the file system's mount option handling code.
>
To clarify: do you mean that per-superblock options would all be
strings and would all get passed down to the fs? If so, I like it. I
think that whatever corresponds to MNT_READONLY shouldn't be passed
down to the filesystem or necessarily specified when loading the
filesystem at all. But MNT_READONLY is a very different thing than
"ro".
--Andy
On Mon, Sep 01, 2014 at 02:23:46PM -0700, Andy Lutomirski wrote:
> To clarify: do you mean that per-superblock options would all be
> strings and would all get passed down to the fs? If so, I like it. I
> think that whatever corresponds to MNT_READONLY shouldn't be passed
> down to the filesystem or necessarily specified when loading the
> filesystem at all. But MNT_READONLY is a very different thing than
> "ro".
So the way I see it, we should be very clear about the distinction
between the mount flags (MS_READONLY) and the mountpoint flags
(MNT_READONLY). The former are set when the file system is "mounted"
via the call to the file system's fill_super function.
The latter is set when the file system is attached to the namespace
via the creation of a mount point. From the perspective of the user
using the mount(8) userspace program, the way I would envision this
working is that the mount(8) progam would query the MS_* flags and use
them to populate the MNT_* flags for the initial mount of the file
system. That way, the user experience gets preserved, but we move all
of the parsing to a single place --- in the kernel.
This would also fix the bug where rootflags=noatime doesn't work,
because today some mount options are parsed in the kernel, and some
are parsed in userspace, and it's really, fundamentally, not fair that
the user should be forced to understand the difference between the
string "acl" and the magic mount flag, MS_READONLY which happens to be
set if "ro" is passed to the mount option alongside "acl".
For MS_READONLY, there's no problem because we do currently make a
hard distinction between MS_READONLY and MNT_READONLY. The two have
distinct meanings, and so I think it makes sense that "ro" be passed
down to the file system alongside "acl", even if there is a library
function which translates "ro" into the standard MS_READONLY flag.
What's more difficult is MS_NOATIME, which exists as a superblock
flag, but it's not actually checked as a superblock flag, except to
decide whether or not to set MNT_NOATIME.
What might make sense is to give the kernel responsibility for parsing
the mountpoint flags as well, so we pass text strings for
corresponding to MNT_NOATIME, etc. to the kernel as well. If the
mountpoint flag isn't specified, then the value of superblock flag
(i.e., MS_NOATIME) gets used as the default.
Cheers,
- Ted