Re: [PATCH] BTRFS-PROG: recursively subvolume snapshot and delete

[Goffredo Baroncelli <kreijack@gmail.com>]

Hi David,
On 2013-11-28 19:31, David Sterba wrote:
> On Sat, Nov 16, 2013 at 06:09:00PM +0100, Goffredo Baroncelli wrote:
>> the following patches implement the recursively snapshotting and
>> deleting of a subvolume. 
> 
> Nice feature, but can we try to make the snapshot creation atomic? This
> would need support from kernel of course.
> 
> I'm worried about the outcome from the users' perspective, the
> consistency of the whole subvolume subtree. As you've implemented it,
> there are several operations involved like traversing the subvolume
> list, replacing the empty-subvols with the real ones, taking the
> snapshots. The assumptions about existing source subvolumes may change
> in the meantime: renamed or deleted.

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.

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.

May be that it could be more simple to snapshot "all the filesystem", ie
snapshot not from the filesystem-tree but form the root-of-tree; then we
could cherry-pick the subvolume which are involved....

Another possibility is to forzen all subvolumes, then snapshot them,
then unfrozen all the subvolume...

> 
> The recursive deletion is safer form this point, I'll look at the
> patches closer. Deleting the whole directory subtree with randomly
> scattered subvolumes is not easy atm, I'm using wrappers around find and
> maxdepth/mindepth to look for subvols and issue delete until it's done.

The patches should be independent. Otherwise if you think that changing
the order it would be more simple to merge them (even without the
recursive-non-atomic-snapshot), let me know.

> 
> 
> david
> 


-- 
gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5