Re: snapshot/subvol deletion

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 08/26/2009 02:50 PM, Chris Mason wrote:
> On Wed, Aug 26, 2009 at 01:25:09PM +0800, Yan, Zheng wrote:
>> On 08/25/2009 11:03 PM, Chris Mason wrote:
>>> On Tue, Aug 25, 2009 at 10:38:01PM +0800, Yan, Zheng wrote:
>>>> 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.
>>>
>>
>> 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.
> 

I thought about it again. I think we can use vfsmount to simulate symbolic's
behavior.

Yan, Zheng
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux