From: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>
To: linux-btrfs@vger.kernel.org
Subject: Re: lazytime mount option—no support in Btrfs
Date: Wed, 22 Aug 2018 07:30:09 -0400 [thread overview]
Message-ID: <3a460831-0924-7615-0977-b32ab82cbece@gmail.com> (raw)
In-Reply-To: <pan$4b9b5$2e5ff999$1d9fa649$483aa66c@cox.net>
On 2018-08-21 23:57, Duncan wrote:
> Austin S. Hemmelgarn posted on Tue, 21 Aug 2018 13:01:00 -0400 as
> excerpted:
>
>> Otherwise, the only option for people who want it set is to patch the
>> kernel to get noatime as the default (instead of relatime). I would
>> look at pushing such a patch upstream myself actually, if it weren't for
>> the fact that I'm fairly certain that it would be immediately NACK'ed by
>> at least Linus, and probably a couple of other people too.
>
> What about making default-noatime a kconfig option, presumably set to
> default-relatime by default? That seems to be the way many legacy-
> incompatible changes work. Then for most it's up to the distro, which in
> fact it is already, only if the distro set noatime-default they'd at
> least be using an upstream option instead of patching it themselves,
> making it upstream code that could be accounted for instead of downstream
> code that... who knows?
That's probably a lot more likely to make it upstream, but it's a bit
beyond my skills when it comes to stuff like this.
>
> Meanwhile, I'd be interested in seeing your local patch. I'm local-
> patching noatime-default here too, but not being a dev, I'm not entirely
> sure I'm doing it "correctly", tho AFAICT it does seem to work. FWIW,
> here's what I'm doing (posting inline so may be white-space damaged, and
> IIRC I just recently manually updated the line numbers so they don't
> reflect the code at the 2014 date any more, but as I'm not sure of the
> "correctness" it's not intended to be applied in any case):
>
> --- fs/namespace.c.orig 2014-04-18 23:54:42.167666098 -0700
> +++ fs/namespace.c 2014-04-19 00:19:08.622741946 -0700
> @@ -2823,8 +2823,9 @@ long do_mount(const char *dev_name, cons
> goto dput_out;
>
> /* Default to relatime unless overriden */
> - if (!(flags & MS_NOATIME))
> - mnt_flags |= MNT_RELATIME;
> + /* JED: Make that noatime */
> + if (!(flags & MS_RELATIME))
> + mnt_flags |= MNT_NOATIME;
>
> /* Separate the per-mountpoint flags */
> if (flags & MS_NOSUID)
> @@ -2837,6 +2837,8 @@ long do_mount(const char *dev_name, cons
> mnt_flags |= MNT_NOATIME;
> if (flags & MS_NODIRATIME)
> mnt_flags |= MNT_NODIRATIME;
> + if (flags & MS_RELATIME)
> + mnt_flags |= MNT_RELATIME;
> if (flags & MS_STRICTATIME)
> mnt_flags &= ~(MNT_RELATIME | MNT_NOATIME);
> if (flags & MS_RDONLY)
>
> Sane, or am I "doing it wrong!"(TM), or perhaps doing it correctly, but
> missing a chunk that should be applied elsewhere?
Mine only has the first part, not the second, which seems to cover
making sure it's noatime by default. I never use relatime though, so
that may be broken with my patch because of me not having the second part.
>
>
> Meanwhile, since broken rootflags requiring an initr* came up let me take
> the opportunity to ask once again, does btrfs-raid1 root still require an
> initr*? It'd be /so/ nice to be able to supply the appropriate
> rootflags=device=...,device=... and actually have it work so I didn't
> need the initr* any longer!
Last I knew, specifying appropriate `device=` options in rootflags works
correctly without an initrd.
next prev parent reply other threads:[~2018-08-22 14:54 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-13 11:50 lazytime mount option—no support in Btrfs Adam Hunt
2017-08-14 13:19 ` Austin S. Hemmelgarn
2018-08-18 20:45 ` waxhead
2018-08-19 8:37 ` Martin Steigerwald
2018-08-19 10:25 ` Andrei Borzenkov
2018-08-20 12:16 ` Austin S. Hemmelgarn
2018-08-21 12:06 ` Adam Borowski
2018-08-21 12:17 ` Austin S. Hemmelgarn
2018-08-21 13:32 ` Janos Toth F.
2018-08-21 14:10 ` Austin S. Hemmelgarn
2018-08-21 16:05 ` David Sterba
2018-08-21 17:01 ` Austin S. Hemmelgarn
2018-08-22 3:57 ` Duncan
2018-08-22 11:30 ` Austin S. Hemmelgarn [this message]
2018-08-23 4:46 ` Duncan
2018-08-22 13:48 ` David Sterba
2018-08-22 13:56 ` Austin S. Hemmelgarn
2018-08-22 15:01 ` David Sterba
2018-08-22 16:59 ` Austin S. Hemmelgarn
2018-08-23 23:33 ` Janos Toth F.
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=3a460831-0924-7615-0977-b32ab82cbece@gmail.com \
--to=ahferroin7@gmail.com \
--cc=linux-btrfs@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).