On Fri, 6 Jul 2007 23:42:01 +1000 David Chinner <dgc@xxxxxxx> wrote: > On Fri, Jul 06, 2007 at 12:26:23PM +0200, Jörn Engel wrote: > > On Fri, 6 July 2007 20:01:10 +1000, David Chinner wrote: > > > On Fri, Jul 06, 2007 at 04:26:51AM +0200, Nick Piggin wrote: > > > > > > But, surprisingly enough, the above work is relevent to this > > > forum because of two things: > > > > > > - we've had to move to direct I/O and user space caching > > > to work around deficiencies in kernel block device caching under > > > memory pressure.... > > > > > > - we've exploited techniques that XFS supports but the VM > > > does not. i.e. priority tagging of cached metadata so that less > > > important metadata is tossed first (e.g. toss tree leaves before > > > nodes and nodes before roots) when under memory pressure. > > > > And the latter is exactly what logfs needs as well. You certainly > > have me interested. > > > > I believe it applies to btrfs and any other cow-fs as well. The > > point is that higher levels get dirtied by writing lower layers. > > So perfect behaviour for sync is to write leaves first, then nodes, > > then the root. Any other order will either cause sync not to sync > > or cause unnecessary writes and cost performance. > > 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. > 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. But, the part where we toss leaves first is definitely useful. -chris - 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
