BTRFS_IOC_SNAP_DESTROY and powerfail

BTRFS_IOC_SNAP_DESTROY and powerfail

[Ellis H. Wilson III]

Hi folks,

I'm looking for some insight on the guarantees of subvolume removal via 
BTRFS_IOC_SNAP_DESTROY.

Presume we have a subvolume under the root of btrfs as such:

/btrfs/subvol

If I issue BTRFS_IOC_SNAP_DESTROY against subvol and then a 
BTRFS_IOC_START_SYNC, and both return, am I guaranteed that subvol is 
gone from the root directory entry even in the face of power failure?

Or am I required to issue and wait for BTRFS_IOC_WAIT_SYNC to return to 
make such a guarantee?

Reading the code for the SNAP_DESTROY IOCTL, it seems that even if I 
just issue that IOCTL, subvol should be gone forever (so long as logs 
aren't lost), and START_SYNC is just a nice-to-have.

Any insight to share on this?

Thanks,

ellis

Re: BTRFS_IOC_SNAP_DESTROY and powerfail

[Nikolay Borisov]

On 9.10.20 г. 21:10 ч., Ellis H. Wilson III wrote:
> Hi folks,
> 
> I'm looking for some insight on the guarantees of subvolume removal via
> BTRFS_IOC_SNAP_DESTROY.
> 
> Presume we have a subvolume under the root of btrfs as such:
> 
> /btrfs/subvol
> 
> If I issue BTRFS_IOC_SNAP_DESTROY against subvol and then a
> BTRFS_IOC_START_SYNC, and both return, am I guaranteed that subvol is
> gone from the root directory entry even in the face of power failure?

Nope, btrfs_delete_subvolume does indeed remove the dentry from the
directory and adds an ORPHAN item but until those modifications of the
in-memory data are persisted on disk a power failure might revert them.
START_SYNC just begins transaction commit but doesn't provide any
guarantees of when changes will be persisted.

> 
> Or am I required to issue and wait for BTRFS_IOC_WAIT_SYNC to return to
> make such a guarantee?
> 
> Reading the code for the SNAP_DESTROY IOCTL, it seems that even if I
> just issue that IOCTL, subvol should be gone forever (so long as logs
> aren't lost), and START_SYNC is just a nice-to-have.

btrfs_delete_subvolume removes the dentry and also sets the unlink
transaction. For more information check comment of
btrfs_record_snapshot_destroy. To have any guarantees whatsoever, even
with fsync you are required to undergo a full transaction commit.

> 
> Any insight to share on this?
> 
> Thanks,
> 
> ellis
> 

Re: BTRFS_IOC_SNAP_DESTROY and powerfail

[Ellis H. Wilson III]

On 10/12/20 1:46 AM, Nikolay Borisov wrote:
> Nope, btrfs_delete_subvolume does indeed remove the dentry from the
> directory and adds an ORPHAN item but until those modifications of the
> in-memory data are persisted on disk a power failure might revert them.
> START_SYNC just begins transaction commit but doesn't provide any
> guarantees of when changes will be persisted.

Thank you very much Nikolay.  We will instead pursue a rename approach, 
fsync that first, and then issue the more expensive subvolume remove in 
the background.  If powerfail brings it back to life it's easy enough to 
re-issue the subvolume remove again as it'll be in a location known to 
house dead subvols.

Thanks again!

ellis