linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: lazytime mount option—no support in Btrfs
Date: Wed, 22 Aug 2018 03:57:14 +0000 (UTC)	[thread overview]
Message-ID: <pan$4b9b5$2e5ff999$1d9fa649$483aa66c@cox.net> (raw)
In-Reply-To: 49b2ad81-256a-981e-cf6c-04e3bf32e932@gmail.com

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?

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?


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!

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

  reply	other threads:[~2018-08-22  7:22 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 [this message]
2018-08-22 11:30                       ` Austin S. Hemmelgarn
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='pan$4b9b5$2e5ff999$1d9fa649$483aa66c@cox.net' \
    --to=1i5t5.duncan@cox.net \
    --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).