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
