Re: Q: what exactly does SSD mode still do?

[Hans van Kranenburg <hans@knorrie.org>]

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