snapshot/subvol deletion

Hi,

I will send a series patches that add snapshot/subvol deletion soon. But the way to delete snapshot/subvol is far from people's expectancy. To delete a snapshot/subvol, we need four steps: 1) snapshot/subvol deletion ioctl or rmdir; 2) umount; 3) btrfsck; 4) mount the fs.

The reason for this is bug in root back & forward references. In simple terms, the bug prevents us from knowing how many places a snapshot/subvol is referenced. So it's unsafe delete corresponding fs tree immediately after a link to snapshot/subvol is removed.

Quoted 11 lines · Zheng

Hi,

I will send a series patches that add snapshot/subvol deletion soon. But the way to delete snapshot/subvol is far from people's expectancy. To delete a snapshot/subvol, we need four steps: 1) snapshot/subvol deletion ioctl or rmdir; 2) umount; 3) btrfsck; 4) mount the fs.

The reason for this is bug in root back & forward references. In simple terms, the bug prevents us from knowing how many places a snapshot/subvol is referenced. So it's unsafe delete corresponding fs tree immediately after a link to snapshot/subvol is removed.

Thanks for working on this, its a major feature. The problem with the forward/backward reference counting is that our links to a subvolume or snapshot are really more like symbolic links than active references.

If a directory entry points to a subvolume and someone uses rm -rf to delete the files inside that subvolume or snapshot, you get the same kind of semantics as deleting the subvolume with the ioctl.

So, we should be able to delete the snapshot without the unmount step. It may create an invalid reference but the code to follow snapshot directory items will have to be changed to deal with that.

If we later on allow root ids to be reused, the directory item pointing to a subvol will again be like a symbolic link. You'll end up in the new subvol instead of the old.

Quoted 21 lines · Chris Mason

Quoted 11 lines · Zheng

Hi,

I will send a series patches that add snapshot/subvol deletion soon. But the way to delete snapshot/subvol is far from people's expectancy. To delete a snapshot/subvol, we need four steps: 1) snapshot/subvol deletion ioctl or rmdir; 2) umount; 3) btrfsck; 4) mount the fs.

The reason for this is bug in root back & forward references. In simple terms, the bug prevents us from knowing how many places a snapshot/subvol is referenced. So it's unsafe delete corresponding fs tree immediately after a link to snapshot/subvol is removed.

Thanks for working on this, its a major feature. The problem with the forward/backward reference counting is that our links to a subvolume or snapshot are really more like symbolic links than active references.

If a directory entry points to a subvolume and someone uses rm -rf to delete the files inside that subvolume or snapshot, you get the same kind of semantics as deleting the subvolume with the ioctl.

Quoted 8 lines

So, we should be able to delete the snapshot without the unmount step. It may create an invalid reference but the code to follow snapshot directory items will have to be changed to deal with that.

If we later on allow root ids to be reused, the directory item pointing to a subvol will again be like a symbolic link. You'll end up in the new subvol instead of the old.

So the problem is the directory entry for the snapshot? What if we just went ahead and added an orphan item for the inode, remove the dir index and dir item's so that it doesn't show up on ls and such, and then the next time we mount the orphan entry gets cleaned up. That way we can skip the fsck altogether. Or am I missing something as per usual?

;) The problem is the directory entry for the snapshot, but its a little more complex. Lets say subvolA has a directory entry for snapshotZ, and then someone wanders in and snapshots subvolA, creating snapshotA'.

This means that both subvolA and snashotA' have a directory entry for snapshotZ. If we delete snapshotZ we have to deal with both directory entries.

Quoted 11 lines · Zheng

Hi,

I will send a series patches that add snapshot/subvol deletion soon. But the way to delete snapshot/subvol is far from people's expectancy. To delete a snapshot/subvol, we need four steps: 1) snapshot/subvol deletion ioctl or rmdir; 2) umount; 3) btrfsck; 4) mount the fs.

The reason for this is bug in root back & forward references. In simple terms, the bug prevents us from knowing how many places a snapshot/subvol is referenced. So it's unsafe delete corresponding fs tree immediately after a link to snapshot/subvol is removed.

Thanks for working on this, its a major feature. The problem with the forward/backward reference counting is that our links to a subvolume or snapshot are really more like symbolic links than active references.

If a directory entry points to a subvolume and someone uses rm -rf to delete the files inside that subvolume or snapshot, you get the same kind of semantics as deleting the subvolume with the ioctl.

So, we should be able to delete the snapshot without the unmount step. It may create an invalid reference but the code to follow snapshot directory items will have to be changed to deal with that.

If we later on allow root ids to be reused, the directory item pointing to a subvol will again be like a symbolic link. You'll end up in the new subvol instead of the old.

Quoted 17 lines · Chris Mason

Quoted 11 lines · Zheng

Hi,

I will send a series patches that add snapshot/subvol deletion soon. But the way to delete snapshot/subvol is far from people's expectancy. To delete a snapshot/subvol, we need four steps: 1) snapshot/subvol deletion ioctl or rmdir; 2) umount; 3) btrfsck; 4) mount the fs.

The reason for this is bug in root back & forward references. In simple terms, the bug prevents us from knowing how many places a snapshot/subvol is referenced. So it's unsafe delete corresponding fs tree immediately after a link to snapshot/subvol is removed.

Thanks for working on this, its a major feature. The problem with the forward/backward reference counting is that our links to a subvolume or snapshot are really more like symbolic links than active references.

Quoted 4 lines

If a directory entry points to a subvolume and someone uses rm -rf to delete the files inside that subvolume or snapshot, you get the same kind of semantics as deleting the subvolume with the ioctl.

I don't think so. For each links to a subvolume, there is a separate dentry. For all symbolic links to a directory, there is only one dentry. So the semantics are different, at least from VFS' point of view.

Quoted 5 lines

So, we should be able to delete the snapshot without the unmount step. It may create an invalid reference but the code to follow snapshot directory items will have to be changed to deal with that.

Quoted 4 lines

If we later on allow root ids to be reused, the directory item pointing to a subvol will again be like a symbolic link. You'll end up in the new subvol instead of the old.

The extent back reference does not allow reusing objectid of deleted root.

Quoted 23 lines · Zheng

Quoted 21 lines · Chris Mason

Quoted 11 lines · Zheng

Hi,

I will send a series patches that add snapshot/subvol deletion soon. But the way to delete snapshot/subvol is far from people's expectancy. To delete a snapshot/subvol, we need four steps: 1) snapshot/subvol deletion ioctl or rmdir; 2) umount; 3) btrfsck; 4) mount the fs.

The reason for this is bug in root back & forward references. In simple terms, the bug prevents us from knowing how many places a snapshot/subvol is referenced. So it's unsafe delete corresponding fs tree immediately after a link to snapshot/subvol is removed.

Thanks for working on this, its a major feature. The problem with the forward/backward reference counting is that our links to a subvolume or snapshot are really more like symbolic links than active references.

If a directory entry points to a subvolume and someone uses rm -rf to delete the files inside that subvolume or snapshot, you get the same kind of semantics as deleting the subvolume with the ioctl.

Quoted 3 lines

I don't think so. For each links to a subvolume, there is a separate dentry. For all symbolic links to a directory, there is only one dentry. So the semantics are different, at least from VFS' point of view.

Yes, in terms of how things are implemented in the VFS, it is different. In terms of the behavior seen by users its a symbolic link. We could actually implement them as symlinks, but I didn't like the idea of having to follow links as part of cp -a.