Block layer discard requests

Block layer discard requests

Posted Aug 14, 2008 5:11 UTC (Thu) by jzbiciak (✭ supporter ✭, #5246)
Parent article: Block layer discard requests

Otherwise, the request goes onto the queue, and the end_io() function will be called when the discard request completes. Most of the time, though, the filesystem will not really care about completion - it's just passing advice to the driver, after all - so end_io() can be NULL and the right thing will happen.

Time for my naive questions: Is there ever a race condition where you could free some number of sectors, and then reallocate them, such that the writes for those sectors somehow get ahead of the trim operation? Is there anything that guarantees the ordering?

I ask because I was under the impression that I/O schedulers like CFQ try to balance among processes, and so it's not clear that a truncate operation from process A remains strongly ordered relative to a file written by process B.

---

(Log in to post comments)

We guarantee the ordering by making discard requests be soft barriers.

What am I missing?  Jon Corbet's article and seanyoung's implementation and possibly willy's
comment above suggest that these trim/punch/discard/... requests are somehow very special in
their reordering requirements, whereas it seems to me that a discard is just the same as a
write: the existing code mustn't reorder any writes to a given block, and the new code mustn't
reorder any write-or-discard requests to a given block.  This shouldn't require any more
barriers or speed penalty than we already have for writes.

(The only difference is that one might use *looser* requirements for reordering discards and
reads for a given block, depending on the semantics of reading a discarded block.)

This was already discussed in the email thread ... overlapping writes are already serialised
by the page lock.  Discard doesn't have a page to lock, so you can't rely on this.