On Tue, 2008-08-12 at 19:10 +0100, Jamie Lokier wrote: > Wouldn't an explicit barrier be (a) slow if it's a hard-barrier, and > (b) as a soft-barrier, overly constrain scheduling, because the only > ordering required is against a subsequent overlapping write? Yes, a soft barrier is more than we need -- but unless we do a lot of work in the schedulers to ensure that writes can't cross discards, that's the best option we have. > Explicit soft or hard barrier *before* DISCARD does need to be an > option. Think of journalling: Step 1 = commit "deleted file" to > journal, 2 = hard barrier, 3 = DISCARD file data. Barrier after does > not seem to be required. The barrier afterwards is to protect against immediate reallocation of these blocks to a new inode, and the associated data write getting scheduled _before_ the discard. -- dwmw2 -- 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
