The Linux Storage and Filesystem Summit, day 1

My thought when I read that is that what we really want is some statistics on dirty data - probably index it by length of sequential area (and track the average sequential size), and some heuristics for how likely dirty data is to be redirtied, if someone can come up with useful ones.

The idea being that if you're say, copying iso files there's no point in queuing up a gigabyte's worth - but bdb doing random io should be allowed to use more memory. Especially if you maintained those statistics per process, you'd be in good shape to do that.

Having never looked at the writeback code I've no idea what it does already, but it seems to me once you're keeping track of sequential chunks of dirty data it seems to me it'd be a great idea to write them out roughly in order of sequential size - writing out the isos you're copying before your berkeley db.