The Linux Storage and Filesystem Summit, day 1

As you say, we'll see what happens.

The problem is mainly that current barriers don't really mean any one thing, they're poorly defined... and what filesystems really need is to know when something is on disk.

Also, ordering is really not a simple matter. It's not just a matter of the disk reordering it... it's the queue, and any virtual block devices in between (raid/lvm/caching (I'm the author of bcache, so this has been on my mind lately). Introducing an artificial global ordering on all the ios you see is a pain in the ass... so if the filesystems don't need it, and it isn't needed for performance, that's a lot of complexity you can cut out.

Personally I think being able to specify an ordering on bios you submit would be a useful thing, partly in filesystem complexity and with higher latency storage it should potentially be a performance gain. But do not think it's a simple thing to implement, or necessary - and the current barriers certainly aren't that, so getting rid of them is a good thing.

I was just thinking today that if we are going to try and implement the ability to order in flight bios, probably the way to do it would be to first implement it only in the generic block layer, _maybe_ the io scheduler at first - and come up with some working semantics. The generic block layer could support it regardless of hardware support simply by waiting to queue a bio until it had no outstanding dependencies.

Such an interface could then live or die depending on if filesystems were actually able to make good use of it - if it makes life harder for them, it's probably not worth it. If it did prove useful, the implementation could be extended down the layers till it got to the hardware.

-------------

Just musing for a bit about what that interface might be - here's a guess:
You probably want a bio to be able to depend on multiple bios, the way that looks sanest to me is add two fields:
atomic_t bi_depends /* bio may not be started until 0 */
struct bio *bi_parent /* if not NULL, decrement bi_parent->bi_depends */

You'd then have to add a bit in bi_flags to indicate error on a depending bio - so it was never started: if when completing a bio, before you decrement bi_parent->bi_depends, if (error) set the error flag on the parent.

With that feature I don't know if you could use NCQ - I'm not a SCSI guy - but without it it seems fairly useless, or else dangerous to use; you can't, for example, rewrite your superblock to point to the new btree root if writing the new root failed. I suppose you could use it if you used a log or a journal to write the current btree root, and then pointers to btree nodes contained the checksum of the node they pointed to - and both are good ideas, but there's still plenty of other situations where you wouldn't be able to recover (and in that case you don't really need write ordering anyways).