On Wed, Oct 24, 2012 at 8:04 PM, <da...@lang.hm> wrote: > On Wed, 24 Oct 2012, Nico Williams wrote: >> COW is "copy on write", which is actually a bit of a misnomer -- all >> COW means is that blocks aren't over-written, instead new blocks are >> written. In particular this means that inodes, indirect blocks, data >> blocks, and so on, that are changed are actually written to new >> locations, and the on-disk format needs to handle this indirection. > > so how can you do this, and keep the writes in order (especially between two > files) without being the filesystem?
By trusting fsync(). And if you don't care about immediate Durability you can run the fsync() in a background thread and mark the associated transaction as completed in the next transaction to be written after the fsync() completes. >> As for fsyn() and background threads... fsync() is synchronous, but in >> this scheme we want it to happen asynchronously and then we want to >> update each transaction with a pointer to the last transaction that is >> known stable given an fsync()'s return. > > If you could specify ordering between two writes, I could see a process > along the lines of > > [...] fsync() deals with just one file. fsync()s of different files are another story. That said, as long as the format of the two files is COW then you can still compose transactions involving two files. The key is the file contents itself must be COW-structured. Incidentally, here's a single-file, bag of b-trees that uses a COW format: MDB, which can be found in git://git.openldap.org/openldap.git, in the mdb.master branch. > Or, as I type this, it occurs to me that you may be saying that every time > you want to do an ordering guarantee, spawn a new thread to do the fsync and > then just keep processing. The fsync will happen at some point, and the > writes will not be re-ordered across the fsync, but you can keep going, > writing more data while the fsync's are pending. Yes, but only if the file's format is COWish. The point is that COW saves the day. A file-based DB needs to be COW. And the filesystem needs to be as well. Note that write ahead logging approximates COW well enough most of the time. > Then if you have a filesystem and I/O subsystem that can consolodate the > fwyncs from all the different threads together into one I/O operation > without having to flush the entire I/O queue for each one, you can get > acceptable performance, with ordering. If the system crashes, data that > hasn't had it's fsync() complete will be the only thing that is lost. With the above caveat, yes. Nico -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
