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

[Jamie Lokier <jamie@shareable.org>]

David Woodhouse wrote:
> > Currently it seems we schedule data direction as READ (no flags).
> > Although I'm not sure, we might want to schedule it as WRITE?  (I guess
> > WRITE can be allowed delay more than READ...)
> 
> I'm not sure it matters much -- this is mostly going to be used on
> devices which aren't affected by I/O scheduling at all and should
> probably be using the no-op scheduler.

One case where it might need I/O scheduling is an
non-volatile-memory-backed ATA/SCSI controller.  (E.g. typical RAID
card with battery, or the newer disks with flash).

You want the schedule, because there are disks behind the controller.
But you want discard requests too, so they can discard from the
non-volatile memory before it hits the disk.

Also, on flash devices there are no seek delays, but even small writes
can take a while, when their internal queues reach a synchronous block
erase state.  If there's lots of WRITES or DISCARDS queued, you
wouldn't want them to affect latency-sensitive READ.

For barriers they're asymmetric.  DISCARD must come after barriers,
but keeping DISCARD before barriers doesn't seem to matter.  Treating
them like WRITE is stronger than necessary but fine.

-- Jamie