From: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>
To: David Howells <dhowells@redhat.com>, Qu Wenruo <quwenruo.btrfs@gmx.com>
Cc: dsterba@suse.cz, clm@fb.com, linux-btrfs@vger.kernel.org, wqu@suse.de
Subject: Re: Are the btrfs mount options inconsistent?
Date: Tue, 21 Aug 2018 10:13:15 -0400 [thread overview]
Message-ID: <5eb21737-9783-f774-5777-e8f759e9b7b6@gmail.com> (raw)
In-Reply-To: <341.1534859015@warthog.procyon.org.uk>
On 2018-08-21 09:43, David Howells wrote:
> Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
>
>> But to be more clear, NOSSD shouldn't be a special case.
>> In fact currently NOSSD only affects whether we will output the message
>> "enabling ssd optimization", no real effect if I didn't miss anything.
>
> That's not quite true. In:
>
> if (!btrfs_test_opt(fs_info, NOSSD) &&
> !fs_info->fs_devices->rotating) {
> btrfs_set_and_info(fs_info, SSD, "enabling ssd optimizations");
> }
>
> the call to btrfs_set_and_info() will turn on SSD.
>
> What this seems to me is that, normally, SSD will be turned on automatically
> unless at least one of the devices is a rotating medium - but this appears to
> be explicitly suppressed by the NOSSD option.
That's my understanding too (though I may be wrong, I'm not an expert on C).
If this _isn't_ what's happening, then it needs to be changed so it is,
that's what the documentation has pretty much always said, and is
therefore how people expect it to work (also, it needs to work because
there needs to be an option other than poking around at sysfs attributes
to disable this on non-rotational media where it's not want4ed).
next prev parent reply other threads:[~2018-08-21 17:33 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-16 11:01 Are the btrfs mount options inconsistent? David Howells
2018-08-16 13:05 ` David Sterba
2018-08-20 12:24 ` David Howells
2018-08-20 12:39 ` Qu Wenruo
2018-08-21 13:43 ` David Howells
2018-08-21 14:13 ` Austin S. Hemmelgarn [this message]
2018-08-21 14:24 ` David Sterba
2018-08-21 14:26 ` Qu Wenruo
2018-08-21 14:35 ` David Howells
2018-08-21 14:40 ` Qu Wenruo
2018-08-20 12:35 ` David Howells
2018-08-21 13:46 ` Do btrfs compression option changes need to be atomic? David Howells
2018-08-21 14:02 ` Chris Mason
2018-08-21 14:20 ` David Sterba
2018-08-21 14:34 ` David Howells
2018-08-21 15:11 ` David Sterba
2018-08-21 16:13 ` David Howells
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=5eb21737-9783-f774-5777-e8f759e9b7b6@gmail.com \
--to=ahferroin7@gmail.com \
--cc=clm@fb.com \
--cc=dhowells@redhat.com \
--cc=dsterba@suse.cz \
--cc=linux-btrfs@vger.kernel.org \
--cc=quwenruo.btrfs@gmx.com \
--cc=wqu@suse.de \
/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).