Hi Neil, Sorry for necro'ing a very old thread. > You still haven't answered my main question, which possibly means I haven't > asked it very clearly. > > You are saying that this new behaviour should not be the default and I think > I agree. > So the question is: how it is selected? > > You cannot expect the user to explicitly enable it any time a resync or > recovery starts that should use this new feature. You must have some > automatic, or semi-automatic, way for the feature to be activated, otherwise > it will never be used. > > I'm not asking "when should the feature be used" - you've answered that > question a few time and it really isn't an issue. > The question it "What it the exact process by which the feature is turned on > for any particular resync or recovery?" > > NeilBrown > Stumbled across this looking for trim and also 'compare and trim rather than write 0's' behavior for md. Personally where a device is non_rotational and support discard this feature would be a big boon. Detecting if a device is non_rotational and testing for discard support should probably be sufficient, this is considered enough for btrfs to switch itself into SSD mode. It is true that older SSDs trim is quite slow. and even now trim causes the SATA queue to be flushed but it's still much better for the life and performance of the majority of current flash devices. If anything for users that know they have a very strange SSD or SSD like device the ability to disable it easy with an option on the rdev would be good. Especially for users that are using md in odd configurations (like 2 remote block devices on arrays that support thin provisioning for example). I know of atleast another user on the linux-raid list that is using md like this and there should also be all the old users of "fast md raid" (predecessor to write-mostly and write intent bitmap) Joseph. -- CTO | Orion Virtualisation Solutions | www.orionvm.com.au Phone: 1300 56 99 52 | Mobile: 0428 754 846 -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
