On Fri, May 25, 2012 at 9:25 AM, Alexander Block <ablock84@xxxxxxxxxxxxxx> wrote: > On Fri, May 25, 2012 at 5:15 PM, Alexander Block > <ablock84@xxxxxxxxxxxxxx> wrote: >> Hello, >> >> I would like to start a discussion on atime in Btrfs (and possibly >> other filesystems with snapshot support). >> >> As atime is updated on every access of a file or directory, we get >> many changes to the trees in btrfs that as always trigger cow >> operations. This is no problem as long as the changed tree blocks are >> not shared by other subvolumes. Performance is also not a problem, no >> matter if shared or not (thanks to relatime which is the default). >> The problems start when someone starts to use snapshots. If you for >> example snapshot your root and continue working on your root, after >> some time big parts of the tree will be cowed and unshared. In the >> worst case, the whole tree gets unshared and thus takes up the double >> space. Normally, a user would expect to only use extra space for a >> tree if he changes something. >> A worst case scenario would be if someone took regular snapshots for >> backup purposes and later greps the contents of all snapshots to find >> a specific file. This would touch all inodes in all trees and thus >> make big parts of the trees unshared. I think you're working from a incorrect understanding: the atime update (metadata) will not cause the data to be de-cow'ed. Even writing to the file will only decow the portion that was written. -- 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
