On Wed, 2015-12-09 at 10:53 +0000, Duncan wrote: > If you use the recipe (subvol create, cp with reflink) it suggests > there, > you'll end up with the reflinked copy in a subvol. > > You can then mount that subvol over top of the existing dir, and > *new* > file opens will access the new subvol, tho existing open files will > of > course continue to access the files/reflinks to which they have a > reference, "underneath" the new mount. Sure, which would mean however that a downtime is still necessary.
> For some services it's possible to signal them to reload their > files. > Where this is possible, you can do the overmount trick and then > signal > them to reload, and they should keep running, otherwise undisturbed > (altho > any changes between the reflink and processing the signal will still > go > to the existing open files, I don't believe there's a way around > that). Yep,.. but as you say,... it doesn't really help to avoid the downtime,... rather lead to data corruption (not on the filesystem level, of course, but within the application). > But AFAIK that's the closest it gets, and nothing more along that > line is > planned. I've been so free to add that idea to the project ideas: https://btrfs.wiki.kernel.org/index.php/Project_ideas#.28Atomically.29_convert_directories_into_subvolumes_and_vice_versa any developer or more experienced user than me is of course free to remove that again, if it seems not so important or isn't possible to be implemented. > In general, keep in mind that subvolumes work in most respects very > much > like normal directories do, except where they don't. =:^) :-P :-P Cheers, Chris.
smime.p7s
Description: S/MIME cryptographic signature
