Linux-BTRFS Archive on lore.kernel.org
 help / color / Atom feed
From: Hans van Kranenburg <hans@knorrie.org>
To: "Holger Hoffstätte" <holger@applied-asynchrony.com>,
	linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: Q: what exactly does SSD mode still do?
Date: Thu, 26 Mar 2020 23:21:18 +0100
Message-ID: <6f49d2cc-c0e4-6d1d-f10d-834089698528@knorrie.org> (raw)
In-Reply-To: <8dcb2f1b-7cb4-cfd4-04ba-7fe4f3c3940b@applied-asynchrony.com>

Hi!

On 3/26/20 7:16 PM, Holger Hoffstätte wrote:
> 
> could someone explain what SSD mode *actually* still does? Not ssd_spread,
> that's clear and unrelated. A recent commit removed the thread-offloaded
> bio submission (avoiding context switches etc.)

Can you share the commit id?

> - which I thought was the
> reason for SSD mode? - and looking through the code I couldn't find any
> bits that helped clarify the difference.

After the change in 2017 to change the extent allocator in ssd mode for
data to behave like nossd already did before, there are two differences
between ssd and nossd left:

1) This if statement in tree-log.c:

cd354ad613a39 (Chris Mason  2011-10-20 15:45:37 -0400 3042)
   /* when we're on an ssd, just kick the log commit out */
0b246afa62b0c (Jeff Mahoney 2016-06-22 18:54:23 -0400 3043)
   if (!btrfs_test_opt(fs_info, SSD) &&

2) Metadata "cluster allocator" write behavior:

*empty_cluster = SZ_64K  # nossd
*empty_cluster = SZ_2M  # ssd

This happens in extent-tree.c.

For 1) I guess this is ok if you can do "seek free writes"?

For 2) I initially wanted to start more research on the behavioral
difference, but when upgrading from Linux 4.9 to 4.19, the majority of
the problems with exploding extent tree metadata writes were already
gone (in ssd mode), so that never happened. So, there's still those two
hard coded values without any proper recent explanation why they should
be at that value.

Hans

  reply index

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-26 18:16 Holger Hoffstätte
2020-03-26 22:21 ` Hans van Kranenburg [this message]
2020-03-27 10:29   ` Holger Hoffstätte
2020-03-28 19:35     ` Zygo Blaxell
2020-03-28 21:31       ` Hans van Kranenburg

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=6f49d2cc-c0e4-6d1d-f10d-834089698528@knorrie.org \
    --to=hans@knorrie.org \
    --cc=holger@applied-asynchrony.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

Linux-BTRFS Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-btrfs/0 linux-btrfs/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-btrfs linux-btrfs/ https://lore.kernel.org/linux-btrfs \
		linux-btrfs@vger.kernel.org
	public-inbox-index linux-btrfs

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-btrfs


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git