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