On Sat, Apr 15, 2017 at 12:50 PM, Adam Borowski <kilob...@angband.pl> wrote: > On Sat, Apr 15, 2017 at 12:41:14PM -0600, Chris Murphy wrote: >> On Sat, Apr 15, 2017 at 12:31 PM, Adam Borowski <kilob...@angband.pl> wrote: >> > On Sat, Apr 15, 2017 at 12:17:25PM -0600, Chris Murphy wrote: >> >> Then later I tried >> >> >> >> mount -o remount,ssd >> >> >> >> To go back to regular ssd option, but nothing happens, mount still >> >> shows ssd_spread. >> > >> > ssd_spread implies ssd. >> >> OK so it's possible to remount from ssd to ssd_spread but not back to >> ssd? If I trust the mount output, it's only possible to transition >> from ssd to ssd_spread, but not from ssd_spread to ssd. > > Yeah. This is a very minor problem (workaround: remount with nossd then > ssd), but in the light of Hans van Kranenburg's findings, it'd be a bad idea > to introduce new mount options the kernel would need to keep recognizing > forever, as the effect of those options needs some rethinking anyways.
Yeah it's confusing aside from the mount behavior. I have a performance test based on doing a bunch of system updates (~100 rpm packages), and even with the same mount options, back to back tests are sufficiently inconsistent that I can't tell which of the allocator options is better. So the allocation options must be about something other than time based performance. I can't tell what is a slow ssd these days so I'm not sure what ssd vs ssd_spread really mean. Plus then on spinning rust people have reported better performance with ssd rather than the default of nossd. While others who are using iSCSI end up with ssd by default and worse results than with nossd. -- Chris Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
