Re: Moving top level to a subvolume

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jun 13, 2012 at 2:21 AM, Arne Jansen <sensille@xxxxxxx> wrote:
> On 13.06.2012 09:04, C Anthony Risinger wrote:
>>
>> a) have a lot of data
>> b) need to do this via script
>> c) ???
>>
>> ... because in a), data will *copied* the slow way, and in b) you
>> leave a bunch of junk laying around in the old root that will rot
>> unless you `rm -rf` it ... [...]
>
> What I don't understand is why you think data will be copied.

at one point i tried to create a new subvol and `mv` files there, and
it took quite some time to complete
(cross-link-device-what-have-you?), but maybe things changed ... will
try it out.

>> [...]
>>
>> so, would it possible to implement this, or could someone kindly (and
>> briefly!) explain why it cannot be done?
>
> The default subvol ('/') has the special number 5 and is expected to
> always be around. All other subvols get numbers starting with 256.
> Creating a new 5 and internally renumbering the old 5 isn't easy, because
> each tree block has an owner recorded in it. Also, all backreferences
> have the root number in them. If you have to touch each tree block, you
> can as well choose the snapshot/rm -rf approach.

ok this makes sense thanks, the last sentence especially ... top-level
volume is different.  it's identical to other subvols in 99% of ways
save one-gotcha-little-1%.  couldn't we shield ourselves a little
better?

>> 1. people install stuff to the top-level
>> 2. top-level is unmanageable
>> 3. ^^^^ problem
>> [...]
>
> Can't instead add code to the installer that warns a user if he wants
> to install into the default subvol?


> Just some random ideas...

i would like to see #5 cut off from natural access: accessible by an
_explicit_ manual mount only, cannot be made default, and cannot be
removed. maybe btrfs manages a proxy/facade subvol, say, #10, settable
by `--flag-origin` or `{insert-here}` option -- a symlink to subvol?
if, at absolutely any time or whatever reason, #10 pointer should not
exist, immediately snapshot #5 and update.

#5 -> #10 -> #256+ ?

... this might allow the root to be "replaced".  default is set to #10
proxy volume when FS is initialized.

> [...]
> Or you could hack mkfs.btrfs to always create an additional subvol.
> Even making / readonly except for creating mountpoint could be possible.

^^^^^ yeah, this sounds like exactly what i'm thinking, differing
mainly on who does the work... i just want a guaranteed way of
replacing the "logical root", at #10.  the "physical root" at #5 it's
more-or-less indestructible and off limits, and never available except
as a template.

... i am new to postgresql, but their template0/template1 feels
related to solving problems like this.

-- 

C Anthony
--
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


[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux