Re: discard and barriers

[Steven Whitehouse <swhiteho@redhat.com>]

Hi,

On Mon, 2010-08-16 at 13:26 +0200, Christoph Hellwig wrote:
> On Mon, Aug 16, 2010 at 10:41:51AM +0100, Steven Whitehouse wrote:
> > GFS2 has a similar concept, which compares two bit maps to generate the
> > extent list to generate the discards. This is done after each resource
> > group has been committed to the journal, and just before the resource
> > group bitmap is updated with the newly freed blocks (and marked dirty).
> > 
> > Any remote node wanting to use that new space will cause a further
> > journal flush when it requests the resource group lock (as well as in
> > place write back of that resource group, of course).
> > 
> > If the local node wants to reuse the recently freed space, then that can
> > happen as soon as the log commit has finished, so in this case the
> > barrier and the waiting are required.
> 
> I don't think you need the barrier for that.  The wait means the
> discard has finished, and from that point writes to the blocks discarded
> are safe.  There's no need to flush the volatile write cache after
> a discard either.  The big question is if you need the drain before
> the discard.  Given that you did a log commit before I suspect not
> as the log commit waits on all I/Os related to this commit.
> 

Yes, that sounds reasonable in that case. I didn't know there were
reordering guarantees with discards vs normal I/O so, in that case there
is no need for the barrier. I don't think anything more is required in
this case, so we should be good to go,

Steve.