On Fri, 6 July 2007 09:52:14 -0400, Chris Mason wrote: > On Fri, 6 Jul 2007 23:42:01 +1000 David Chinner <dgc@xxxxxxx> wrote: > > > Hmmm - I guess you could use it for writeback ordering. I hadn't > > really thought about that. Doesn't seem a particularly efficient way > > of doing it, though. Why not just use multiple address spaces for > > this? i.e. one per level and flush in ascending order. Interesting idea. Is it possible to attach several address spaces to an inode? That would cure some headaches. > At least in the case of btrfs, the perfect order for sync is disk > order ;) COW happens when blocks are changed for the first time in a > transaction, not when they are written out to disk. If logfs is > writing things out some form of tree order, you're going to have to > group disk allocations such that tree order reflects disk order somehow. I don't understand half of what you're writing. Maybe we should do another design session on irc? At any rate, logfs simply writes out blocks. When it is handed a page to write, the corresponding block is written. Allocation happens at writeout time, not earlier. Each written block causes a higher-level block to get changed, so that is written immediatly as well, until the next higher level is the inode. I would like to instead just dirty the higher-level block, so that multiple changes can accumulate before indirect blocks are written. And I have no idea how transactions relate to all this. > But, the part where we toss leaves first is definitely useful. Shouldn't LRU ordering already do that. I can even imagine cases when leaves should be tossed last and LRU ordering would dtrt. Jörn -- The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague. -- Edsger W. Dijkstra - 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
