Re: btrfs-progs: suggestion of removing --commit-after option of subvol delete

[Qu Wenruo <quwenruo.btrfs@gmx.com>]

On 2017年09月19日 22:48, David Sterba wrote:
> On Tue, Sep 19, 2017 at 04:50:04PM +0900, Misono, Tomohiro wrote:
>> I read the code of "subvolume delete" and found that --commit-after option is
>> not working well.
>>
>> Since it issues BTRFS_IOC_START/WAIT_SYNC to the last fd (of directory
>> containing the last deleted subvolume),
>> 1. sync operation affects only the last fd's filesystem.
>>     ("subvolume delete" can take multiple subvolumes on different filesystems.)
> 
> You're right, though I don't think this is a common usecase.
> 
>> 2. if the last delete action fails to open the path (fd == -1),
>>     SYNC is not issued at all.
>>
>> One solution is to keep every fd for deleted subvolumes, but I think it takes
>> too much cost.
> 
> How do you evaluate the cost? We'd have to keep track of all the
> distinct filesystems of the subvolumes, so we issue sync on each of them
> in the end.

The costly part will be tracking the filesystems of subvolumes.
We must do it for each subvolume and batch them to address the final 
transaction commit for each fs.

I didn't see any easy ioctl to get the UUID from fd, meaning (if didn't 
miss anything) we need to iterate the path until reaching the mount 
boundary and then refer to mountinfo to find the fs.

Not to mention that the possible softlink in the path may make things 
more complex.

Yes, this may be fixed with tons of code, but I don't think the 
complexity worthy for a minor feature.
(Remember how --rootdir get untested and buggy over time? And we even 
don't know how to make test case to verify --commit-after/each)

Thanks,
Qu

> 
>> Since we can just use "btrfs filesystem sync" after delete if
>> needed, I think it is ok to remove --comit-after option.
> 
> The point of the option is to allow the sync in the same command as the
> subvolume deletion. Even with the sync, the user would still have to
> know all the filesystems where the the subvolumes were, so some way of
> tracking them would need to be done.
> 
> I don't want to remove the option unless it's really not working as
> expected and could mislead the users. What you found are bugs that can
> be fixed.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>