From mboxrd@z Thu Jan 1 00:00:00 1970 From: Shaohua Li Subject: Re: [RFC 1/2] MD: raid5 trim support Date: Wed, 18 Apr 2012 08:58:14 +0800 Message-ID: <4F8E11A6.7090305@kernel.org> References: <20120417083552.483324288@kernel.org> <20120417084632.306032602@kernel.org> <20120418062641.000e881c@notabene.brown> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20120418062641.000e881c@notabene.brown> Sender: linux-raid-owner@vger.kernel.org To: NeilBrown Cc: Dan Williams , linux-raid@vger.kernel.org, axboe@kernel.dk, Shaohua Li List-Id: linux-raid.ids On 4/18/12 4:26 AM, NeilBrown wrote: > On Tue, 17 Apr 2012 07:46:03 -0700 Dan Williams > wrote: > >> On Tue, Apr 17, 2012 at 1:35 AM, Shaohua Li 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