Jens Axboe <axboe@xxxxxxxxx> writes: >>> The problem is really that the WRITE_SYNC is (for Jan's case) behaving >>> like buffered writes, so it eats up a queue of requests very easily. On >>> the allocation side, the assumption is that WRITE_SYNC behaves like >>> dependent reads. Similar to a dd with oflag=direct, not like a flood of >>> requests. For dependent sync writes, our current behaviour is fine, we >>> treat them like reads. For commits of WRITE_SYNC, they should be treated >>> like async WRITE instead. >> Yeah. But it's similar to what happens when you run fsync() on a large >> dirty file. That will also submit a lot of WRITE_SYNC requests... kjournald >> could probably use WRITE instead of WRITE_SYNC for large commits. It's just >> that we don't really want to give e.g. DIO a preference over kjournald >> because transaction commit can effectively block any metadata changes on >> the filesystem. > > Sure, I'm not advocating against changing WRITE_SYNC, we just need to be > able to handle it a bit better. I've got a test patch, will post it > later. Jens, did you ever post your test patch? -Jeff -- 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
