On Thu, Oct 05, 2017 at 05:03:47PM +0800, Anand Jain wrote: > On 10/05/2017 04:22 PM, Nikolay Borisov wrote: > > Currently when a read-only snapshot is received and subsequently its ro property > > is set to false i.e. switched to rw-mode the received_uuid of that subvol remains > > intact. However, once the received volume is switched to RW mode we cannot > > guaranteee that it contains the same data, so it makes sense to remove the > > received uuid. The presence of the received_uuid can also cause problems when > > the volume is being send. > > Wonder if this [1] approach was considered > [1] > - set a flag on the subvolume to indicate its dirtied so that > received_uuid can be kept forever just in case if user needs it for some > reference at a later point of time. Yeah, we need to be careful here. There are more items related to the recived subvolume, besides received_uuid there's rtransid and rtime so they might need to be cleared as well. I don't remember all the details how the send/receive and uuids interact. Switching from ro->rw needs to affect the 'received' status, but I don't know how. The problem is that some information is being lost although it may be quite important to the user/administrator. In such cases it would be convenient to request a confirmation via a --force flag or something like that. -- 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
