On Fri, Mar 31, 2017 at 10:24:57PM +0200, Hans van Kranenburg wrote: > >> Adding the 'nossd_spread' would be good to have, even if it might be > >> just a marginal usecase. > > Please no, don't make it more complex if not needed. The only use is when ssd,ssd_spread are on and then I'd just want to disable ssd_spread, without disabling ssd at the same time. 1. mount -o ssd,ssd_spread 2. mount -o remount,nossd_spread compared to 1. mount -o ssd,ssd_spread 2. mount -o remount,nossd 3. mount -o remount,ssd I'd vote for adding nossd_spread, as the 'no-' options are common and otherwise disabling ssd_spread would be another usage exception. > > Not sure if there's much point. In any case, that's a separate patch. > > Should I add one while we're here? > > Since the whole ssd thing is a bit of a joke actually, I'd rather see it > replaces with an option to choose an extent allocator algorithm. Yeah, SSD is not the shiny new tech anymore, so we'd need something more future proof. > The amount of if statements using this SSD things in btrfs in the kernel > can be counted on one hand, and what they actually do is quite > questionable (food for another mail thread). That's right, do you have suggestions for futher SSD optimizations? Other than better block alignment, faster flushes and no seek penalty, I don't see much else. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
