Re: [RFC 1/2] MD: raid5 trim support

[Shaohua Li <shli@xxxxxxxxxx>]

On 4/18/12 4:26 AM, NeilBrown wrote:
> On Tue, 17 Apr 2012 07:46:03 -0700 Dan Williams<dan.j.williams@xxxxxxxxx>
> wrote:
>
> > On Tue, Apr 17, 2012 at 1:35 AM, Shaohua Li<shli@xxxxxxxxxx>  wrote:
> > > Discard for raid4/5/6 has limitation. If discard request size is small, we do
> > > discard for one disk, but we need calculate parity and write parity disk.  To
> > > correctly calculate parity, zero_after_discard must be guaranteed.
> >
> > I'm wondering if we could use the new bad blocks facility to mark
> > discarded ranges so we don't necessarily need determinate data after
> > discard.
> >
> > ...but I have not looked into it beyond that.
> >
> > --
> > Dan
>
> No.
>
> The bad blocks framework can only store a limited number of bad ranges - 512
> in the current implementation.
> That would not be an acceptable restriction for discarded ranges.
>
> You would need a bitmap of some sort if you wanted to record discarded
> regions.
>
> http://neil.brown.name/blog/20110216044002#5

This appears to remove the unnecessary resync for discarded range after 
a crash
or discard error, eg an enhancement. From my understanding, it can't 
remove the
limitation I mentioned in the patch. For raid5, we still need discard a 
whole
stripe (discarding one disk but writing parity disk isn't good).

Thanks,
Shaohua
--
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