On Tue, Nov 8, 2016, at 03:00 PM, Hugo Mills wrote: > On Tue, Nov 08, 2016 at 02:48:56PM -0800, Ian Kelling wrote: > > It seems to be an artificially imposed limitation which hurts which > > hurts its usefulness. Let me know if this makes sense. If so, perhaps it > > can be implemented eventually. It seems a bit obvious but I couldn't > > find any existing discussion of it. > > It's not artificial -- it's ensuring safety of operation. No, it doesn't ensure the subvolume is not modified, so it IS artificial. I can still set the subvolume to rw before or probably during the send and modify a file and mess things up. > > If the sender sends an incremental stream, that assumes an *exact* > subvol state on the receiving side. If the subvol on the receiving > side is modified, then the receive can fail. No. The reading program never needs to have access to rw files if it's reading from a read-only mountpoint while the subvolume is rw and mounted as such elsewhere. And a reading program does not magically risk writes. > > So, the assumption is that the reference subvol on the receiving > side (equivalent to the -p subvol on the sending side) hasn't been > changed since it was received. The same assumption applies to the -p > subvol on the sending side. > > Now, receive is a fully userspace tool, so it would have to set the > subvol to RW, then update it, then set it to RO. The subvol risks > being modified by other processes during that window -- *particularly* > if it's actively being read by those other processes. No. The reading program never needs to have access to rw files if it's reading from a read-only mountpoint while the subvolume is rw and mounted as such elsewhere. And a reading program does not magically risk writes. > > Note that this is still an issue with the current situation, but > the expectation is that nothing's going to be actively reading that > location at the time the receive is running. But, if something does go > wrong with the receive, it's possible to abort and restart the > process. If you're modifying an existing subvol, there's no > recoverability if something goes wrong halfway through. No. You could recover using the snapshot that I mentioned. > Hugo. So my question still stands. -- 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
