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. -- 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
