On Fri, Nov 07 2008, Ric Wheeler wrote: > Jens Axboe wrote: > >On Thu, Nov 06 2008, David Woodhouse wrote: > > > >>On Thu, 6 Nov 2008, James Bottomley wrote: > >> > >>>The way to do this properly would be to run a chequerboard of partials, > >>>but this would effectively have trim region tracking done in the block > >>>layer ... is this worth it? > >>> > >>>By the way, the latest (from 2 days ago) version of the Thin > >>>Provisioning proposal is here: > >>> > >>>http://www.t10.org/ftp/t10/document.08/08-149r4.pdf > >>> > >>>I skimmed it but don't see any update implying that trim might be > >>>ineffective if we align wrongly ... where is this? > >>> > >>I think we should be content to declare such devices 'broken'. > >> > >>They have to keep track of individual sectors _anyway_, and dropping > >>information for small discard requests is just careless. > >> > > > >I agree, seems pretty pointless. Lets let evolution take care of this > >issue. I have to say I'm surprised that it really IS an issue to begin > >with, are array firmwares really that silly? > > > >It's not that it would be hard to support (and it would eliminate the > >need to do discard merging in the block layer), but it seems like one of > >those things that will be of little use in even in the near future. > >Discard merging should be useful, I have no problem merging something > >like that. > > > > > I think that discard merging would be helpful (especially for devices > with more reasonable sized unmap chunks). Indeed, and it fits in well with what we do already. Dave has this mostly done I think, so 2.6.29 should be a potential target provided that it gets sent soon :-) -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
