Hugo Mills posted on Tue, 06 Mar 2012 11:29:58 +0000 as excerpted: > The "in-memory buffer" is simply the standard Linux block layer and FS > cache: When a piece of metadata is searched for, btrfs walks down the > relevant tree, loading each tree node (a 4k page) in turn, until it > finds the metadata. Unless there is a huge amount of memory pressure, > Linux's block cache will hang on those blocks in RAM. > > btrfs can then modify those blocks as much as it likes, in RAM, as > userspace tools request those changes to be made (e.g. writes, deletes, > etc). By the CoW nature of the FS, modifying a metadata block will also > require modification of the block above it in the tree, and so on up to > the top of the tree. If it's all kept in RAM, this is a fast operation, > since the trees aren't usually very deep(*). > > At regular intervals (30s), the btrfs code will ensure that it has > a consistent in-memory set of blocks, and flushes those dirty blocks to > disk, ensuring that they're moved from the original location. It does so > by first writing all of the tree data, sending down disk flush commands > to ensure that the data gets to disk reliably, and then writing out new > copies of the superblocks so that they point to the new trees. Thanks for this and the (snipped) rest. It's nice to know a bit of detail at a level below where I was, tho while it makes sense, I suspect it may take reading it more than once to sink in. =:^( But I expect by sticking around I'll get that chance. =:^) Thanks for the truer checksumming picture as well. =:^) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
