On 2013-11-29 19:07, David Sterba wrote: > On Thu, Nov 28, 2013 at 08:23:13PM +0100, Goffredo Baroncelli wrote: >> Definetely you are right. In fact this is true also for other tools like >> tar: they complaint if you remove/move/rename a file during the copy. We >> can work to increase the robustness of the process, to avoid strange >> behaviour when a subvolume is removed/moved/renamed. >> >> Anyway I am more afraid that we can't mix recursive and readonly snapshot. > > Agreed, this would eg. need to toggle RO/RW status when needed, but this > does not sound very clean.
IIRC the RO flags is mandatory for the send/receive; this basically means that we wouldn't be able to use a recursive snapshot with send/receive. > >> Implementing the atomic recursive snapshot in the kernel, is out of my >> possibility; anyway basically this means that the filesystem is frozen >> until all the snapshot are done, which requires a finite time. In case >> of a high number of subvolumes this could be a problem. > > High number of subvolumes to snapshot atomically will always be > problematic and a lazy userspace-based recursive snapshot might be > actually better regarding the impact on the rest of the system, but > without guaranteed atomicity. > > But, I don't want to kill the whole idea just because there's some > scenario that's possible but hard to handle. > > david > -- 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
