Re: [PATCH 0/7] Discard requests, v2

[David Woodhouse <dwmw2@infradead.org>]

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