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 beelevated out of dm-ioctl.c to fs/ioctl.c and exposed, such that anyfilesystem which implements .write_super_lockfs can be frozen? This isessentially what the xfs_freeze userspace does viaxfs_ioctl/XFS_IOC_FREEZE - which, AFAIK, isn't used much now that thelvm 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'redone, and you can only unfreeze then. Shouldn't this be doneprogrammatically, and not with some pre-determined timeout?