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.tomoh...@jp.fujitsu.com) -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html