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 -- 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
