On Wed, Sep 29, 2010 at 02:45:29PM -0400, Yuehai Xu wrote: > On Wed, Sep 29, 2010 at 1:08 PM, Sean Bartell <[email protected]> > wrote: > > On Wed, Sep 29, 2010 at 11:30:14AM -0400, Yuehai Xu wrote: > >> I know BTRFS is a kind of Log-structured File System, which doesn't do > >> overwrite. Here is my question, suppose file A is overwritten by A', > >> instead of writing A' to the original place of A, a new place is > >> selected to store it. However, we know that the address of a file > >> should be recorded in its inode. In such case, the corresponding part > >> in inode of A should update from the original place A to the new place > >> A', is this a kind of overwrite actually? I think no matter what > >> design it is for Log-Structured FS, a mapping table is always needed, > >> such as inode map, DAT, etc. When a update operation happens for this > >> mapping table, is it actually a kind of over-write? If it is, is it a > >> bottleneck for the performance of write for SSD? > > > > In btrfs, this is solved by doing the same thing for the inode--a new > > place for the leaf holding the inode is chosen. Then the parent of the > > leaf must point to the new position of the leaf, so the parent is moved, > > and the parent's parent, etc. This goes all the way up to the > > superblocks, which are actually overwritten one at a time. > > You mean that there is no over-write for inode too, once the inode > need to be updated, this inode is actually written to a new place > while the only thing to do is to change the point of its parent to > this new place. However, for the last parent, or the superblock, does > it need to be overwritten?
Yes. The idea of copy-on-write, as used by btrfs, is that whenever *anything* is changed, it is simply written to a new location. This applies to data, inodes, and all of the B-trees used by the filesystem. However, it's necessary to have *something* in a fixed place on disk pointing to everything else. So the superblocks can't move, and they are overwritten instead. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
