On Mon, Jun 21, 2010 at 08:58:51PM +0200, Jens Axboe wrote: > It's definitely a win in some cases, as you showed there as well. > My initial testing a long time ago had some nice benefits too. So > perhaps the above wasn't worded very well, I always worry that we > have regressions doing boosts for things like that. But given that > meta data is something that needs to be done before we get to the > real data, bumping priority generally seems like a good thing to do. Even if the REQ_META special casing helps with performance it creates a big issue if we want to follow your other guide line, that is marking all actual metadata requests REQ_META for blocktrace. What about only applying the metadata preference only to _synchronous_ (read or REQ_SYNC) I/Os that also have REQ_META set? Right now we never use REQ_META on a non-synchronous request (XFS appears to, but the code is not actually reachable anymore), so it's not actually a change in behaviour. After that we could do an easy sweep through the tree and mark all metadata requests as REQ_META. Btw, what do we consider metadata for this purpose? The interesting question here is about indirect blocks / bmap btree blocks. In the traditional sense they are metadata, but for I/O purposes they are mostly part of the I/O stream. -- 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
