On Fri, 12 Sep 2008, David Woodhouse wrote: > On Fri, 2008-09-12 at 16:52 +0100, Hugh Dickins wrote: > > On Fri, 12 Sep 2008, David Woodhouse wrote: > > > On Fri, 2008-09-12 at 13:10 +0100, Hugh Dickins wrote: > > > > So long as the I/O schedulers guarantee that a WRITE bio submitted > > > > to an area already covered by a DISCARD_NOBARRIER bio cannot pass that > > > > DISCARD_NOBARRIER - ... > > > > > > No, that's the point. the I/O schedulers _don't_ give you that guarantee > > > at all. They can treat DISCARD_NOBARRIER just like a write. That's all > > > it is, really -- a special kind of WRITE request without any data. > > > > Hmmm. In that case I'll need to continue with DISCARD_BARRIER, > > unless/until I rejig swap allocation to wait for discard completion, > > which I've no great desire to do. I'll leave it to Jens to comment on your reply, but I'd like to go back and add in a further, orthogonal concern or misunderstanding here. Am I right to be a little perturbed by blk_partition_remap() and the particular stage at which it's called? Does it imply that a _BARRIER on swap would have the effect of inserting a barrier into, say, root and home I/Os too, if swap and root and home were in separate partitions on the same storage? Whereas a filesystem would logically only want a barrier to span its own partition? (I'm ignoring md/dm.) Hugh -- 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
