H Peter, ----- Original Message ----- > From: "Peter Grandi" <pg@xxxxxxxxxxxxxxxxxxx> > To: "Linux RAID" <linux-raid@xxxxxxxxxxxxxxx> > Sent: Wednesday, January 25, 2012 8:55:37 AM > Subject: Re: LVM striping RAID volumes > > It would be nice if MD passed on TRIM or at least FITRIM, and I > have just done a search and there is a discussion of some issues > with that here: > > http://lkml.indiana.edu/hypermail/linux/kernel/1011.2/02184.html > > «the only really complex part is sending something like that > into MDraid, because that one set of ranges might explode into > thousands of ranges and then have to be coalesced back down to > a more manageable number of ranges. > > ie. with a simple raid 0, each range will need to be broken > into a bunch of stride sized ranges, then the contiguous > strides on each spindle coalesced back into larger ranges. > > But if MDraid can handle discards now with one range, it > should not be that hard to teach it handle a group of ranges.» > > This perplexes me because the logic should be identical to that > of writing: TRIM is in effect a variant of WRITE. > -- That comment perplexes me as well. Who cares how many TRIMs go down into the slave devices? My understanding is that it was the drive's job to figure out TRIM-coalescing on it's own - the block queue limits at the very least specify a "max discard" size, not a minimum one. (btw FITRIM is an fs ioctl afaik, it gets translated into REQ_DISCARDs). Anyway, I was just looking at supporting REQ_DISCARD within RAID1. I don't see it being any different than handling other BIO flags like REQ_FUA etc. The only bit to watch out for are not sending DISCARDs to a device which doesn't support them. I was looking at discard as part of some other investigation which I will write about at a later point, but if there was specific interest, I could refactor it out and post it for review. A -- 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
