I have been testing btrfs send/receive. I like it. During those tests I discovered that it is possible to access and modify (add files, delete files ...) of the new receive snapshot during the transfer. After the transfer it becomes readonly but it could already have been modified.
So you can end up with a source and a destination which are not the same. Therefore during a subsequent incremental transfers I can get receive to crash (trying to unlink a file that is not in the parent but should). Is this behavior by design or will it be prevented in the future? I can of course just not modify the subvolume during receive but is there a way to make sure no user/program modifies it? I can also get in the same kind of trouble by modifying a parent (after changing its property temporarily to ro=false). send/receive is checking that the same parent uuid is available on both sides but not that generation has not changed. Of course in this case it requires direct user intervention. Never changing the ro property of subvolumes would prevent the problem. Again is this by design? Otherwise I would suggest finding a way to avoid those conditions (using the generation maybe?). There could be an override option to allow more flexibility if needed. Thanks Christian -- 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
