[lkml]   [2012]   [May]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    Subjectatime and filesystems with snapshots (especially Btrfs)

    (this is a resend with proper CC for linux-fsdevel and linux-kernel)

    I would like to start a discussion on atime in Btrfs (and 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.

    relatime (which is the default) reduces this problem a little bit, as
    it by default only updates atime once a day. This means, if anyone
    wants to test this problem, mount with relatime disabled or change the
    system date before you try to update atime (that's the way i tested

    As a solution, I would suggest to make noatime the default for btrfs.
    I'm however not sure if it is allowed in linux to have different
    default mount options for different filesystem types. I know this
    discussion pops up every few years (last time it resulted in making
    relatime the default). But this is a special case for btrfs. atime is
    already bad on other filesystems, but it's much much worse in btrfs.


     \ /
      Last update: 2012-05-25 18:01    [W:0.024 / U:1.140 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site