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

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

On 2017年09月19日 15:50, Misono, Tomohiro wrote:
> Hello,
> 
> 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.)
> 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. Since we can just use "btrfs filesystem sync" after delete if
> needed, I think it is ok to remove --comit-after option.

Personally speaking I'm OK removing --commit-after, as implementing a 
full working --commit-after seems too complex for a minor feature.
(Need to finding the same fs of multiple subvolume and doing commit for 
each fs, and fallback to other fd if open failed)

Since --commit-after is a relatively lightweight solution compared to 
--commit-each, and both can only ensure subvolume doesn't show up, while 
"fi sync" can do a "deeper" sync to ensure the whole subvolume get 
removed on disk.

But instead of deleting the option, it would be better to keep it 
deprecated for a while.
Showing a message informing user this option is deprecated and falling 
back to --commit-each seems to be a better solution.

Thanks,
Qu
> 
> Regards,
> Tomohiro Misono
> (misono.tomohiro@jp.fujitsu.com)
> 
> --
> 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
>