[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140829225649.GC27177@thunk.org>
Date: Fri, 29 Aug 2014 18:56:49 -0400
From: Theodore Ts'o <tytso@....edu>
To: Eric Sandeen <sandeen@...hat.com>
Cc: Tomasz Chmielewski <mangoo@...g.org>, linux-ext4@...r.kernel.org,
luto@...capital.net
Subject: Re: tune2fs and setting noatime as a default mount options
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. :-/
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists