[lkml]   [2008]   [Jan]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC] ext3 freeze feature
    Theodore Tso wrote:
    > The other approach would be to say, "oh well, the freeze ioctl is
    > inherently dangerous, and root is allowed to himself in the foot, so
    > who cares". :-)

    I tend to agree. Either you need your fs frozen, or not, and if you do,
    be prepared for the consequences.

    > But it was this concern which is why ext3 never exported freeze
    > functionality to userspace, even though other commercial filesystems
    > do support this. It wasn't that it wasn't considered, but the concern
    > about whether or not it was sufficiently safe to make available.

    What's the safety concern; that the admin will forget to unfreeze?

    > And I do agree that we probably should just implement this in
    > filesystem independent way, in which case all of the filesystems that
    > support this already have super_operations functions
    > write_super_lockfs() and unlockfs().

    That's what I was thinking; can't the path to freeze_bdev just be
    elevated out of dm-ioctl.c to fs/ioctl.c and exposed, such that any
    filesystem which implements .write_super_lockfs can be frozen? This is
    essentially what the xfs_freeze userspace does via
    xfs_ioctl/XFS_IOC_FREEZE - which, AFAIK, isn't used much now that the
    lvm hooks are in place.

    I'm also not sure I see the point of the timeout in the original patch;
    either you are done snapshotting and ready to unfreeze, or you're not;
    1, or 2, or 3 seconds doesn't really matter. When you're done, you're
    done, and you can only unfreeze then. Shouldn't this be done
    programmatically, and not with some pre-determined timeout?


     \ /
      Last update: 2008-01-25 17:37    [W:0.020 / U:12.280 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site