On 05/07/2014 01:39 PM, Marc MERLIN wrote: > On Wed, May 07, 2014 at 11:35:52AM +0000, Duncan wrote: >> Marc MERLIN posted on Wed, 07 May 2014 01:56:12 -0700 as excerpted: >> >>> On Tue, May 06, 2014 at 04:26:48PM +0000, Duncan wrote: >>>> Marc MERLIN posted on Sun, 04 May 2014 22:04:59 -0700 as excerpted: >>>> >>>>> >>>>> Aaah, right, you can use a script to see the file differences between >>>>> two snapshots, and then restore that with reflink if you can truly >>>>> get a list of all changed files. >>>>> However, that is indeed not atomic at all, even if faster than rsync. >>>> >>>> Would send/receive help in such a script? >>> >>> Not really, you still end up with a new snapshot that you can't live >>> switch to. >>> >>> It's really either 1) reboot 2) use cp --reflink to copy a list of >>> changed files (as well as rm to delete the ones that were removed). >> >> What I meant was... use send/receive locally, in place of the >> cp --reflink. > > This won't work since it can only work on another read-only subvolume. > > But you could use btrfs send -p to get a list of changes between 2 > snapshots, decode that (without btrfs receive) just to spit out the > names of the files that changed or got deleted. > It would be wasteful since it would cause all the changed blocks to be > read on the source, but still better than nothing. > > Really, we'd just need a btrfs --send --dry-run -v -p vol1 vol2 > which would spit out a list of the file ops it would do. > > That'd be enough to simply grep out the deletes, do them locally and > then use cp --reflink on everything else.
What happens to the already opened files ? I suppose that a process which has already opened a file, see the old one; instead a new open could see the new one. If this is acceptable, why not doing "mount --bind /snapshot /", or use pivot_root(2), or a overlay filesystem ? May be that we need to move also the other already mounted_filesystem (like /proc, /sys)... > > Marc > -- gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it> Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 -- 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