[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: booting btrfs
From: |
Michael Chang |
Subject: |
Re: booting btrfs |
Date: |
Mon, 30 Dec 2013 18:18:16 +0800 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
On Mon, Dec 23, 2013 at 08:43:34PM -0700, Chris Murphy wrote:
>
> On Dec 23, 2013, at 7:26 PM, Michael Chang <address@hidden> wrote:
>
> > Now I tend to agree that supporting config for snapshot booting
> > shouldn't be upstream's consideration due to it's compliexity and
> > dependency to system, Despite on this, I still like to ask : Did
> > upstream think about any patch trying to provide relative path support
> > for btrfs subvolume name or id's a worthy work or not?
>
> My vague recollection is that it did used to work this way before 2.00, but
> maybe was unintended?
It used to follow relative path of set-default volume, but was reverted
to always use absolute path of real root. It's similar to my question
but mine is to have a path intepretation per any subvolume set via
environment variable or so.
It will work like this way.
set btrfs_subvol=.snapshot_1
<All path intepretation by the .snapshot_1 subvolume ..>
set btrfs_subvol=.snapshot_2
<All path intepretation by the .snapshot_2 subvolume ..>
But this would bring ambiguous path back that I'm not sure a good idea
or not to have such feature.
>
> > Thanks. It can be a solution for some use cases but for the one I
> > want to achieve it's insufficent. What I'm looking for is to list the
> > available snapshots in the boot menu for selecting and then booting to
> > it.
>
> OK in that case the tool creates the snapshots, modifies its fstab, and
> updates grub.cfg so they're displayed.
>
> Direct editing of grub.cfg is fragile in that the user could run
> grub-mkconfig at any time. It's better for the tool to use an existing entry
> as a template, and add snapshot entries to 40_custom, then run grub-mkconfig.
Yes. I think this is suggested approch for modifying grub configs.
What bothers me in hooking into grub-mkconfig is it takes time to
finish the "entire" config and will slow down snapshot tools in
creating the snapshot if we hook grub-mkconfig into it's post
processing scripts.
Does offer an option like `--run-script=90_btrfs_snapshot` to
grub-mkconfig feasible or not? My apologies if this is off topic
here.
Regards,
Michael
>
> Another thing to note is that there are UEFI computers shipping that don't
> have USB initialized by the firmware by default at boot time. So the user
> couldn't use this menu on such systems - which some have suggested will
> become increasingly common. This implies a snapshot tool that provides the UI
> to choose snapshots prior to rebooting into that snapshot.
>
> > Meanwhile the snapshot is not for os installation,
> > people occasionally want to boot into it for special reasons like he
> > want to find from when his system performance start downgrading. I'd
> > consider such multiboot should not consider os installtion be in
> > snapshots .. because it makes no sense.
>
> I understand. I mean it's eventually feasible for a single Btrfs volume to
> contain multiple distributions in their own subvolumes, because Btrfs volumes
> are designed to be large, and easily extend to multiple devices.
>
> It's essentially the same as multiboot without Btrfs at all, the core.img
> would point to a stable "master" grub.cfg that in turn uses configfile to
> point to the grub.cfg for each distribution. Each distribution maintains its
> own grub.cfg without modifying the "master" that core.img is pointing to. It
> would be nice if distributions made this configuration easy for users to
> implement.
>
> I think this might be better than doing it with set-default and leave that
> strictly a user domain function/short cut to being able to mount without -o
> subvol= option.
>
> >
> >>
> >> I think the idea of snapshots in the domain of a boot manager/boot loader
> >> is really overly complicated. For another thing, it's not really
> >> appropriate to do a rollback and then immediately start modifying it by
> >> booting from it. What you'd want to do is snapshot the rollback, and then
> >> use that "cloned" copy of the rollback, leaving the original rollback in
> >> place. Otherwise the provenance of that <inserttime> snapshot is
> >> obliterated.
> >
> > I think that's like seed device and yes there should have such
> > handling in initrd to use a clone copy of read-only snapshots when
> > your kernel parameters are asking to mount it as /.
>
> Yes good point. Your snapshot tool could first create a read only snapshot,
> then for no space cost also create a rw snapshot of the read only one, then
> add the rw snapshot to the grub.cfg. The tool could give the user the option
> to always "revert" the changes caused by booting a snapshot - this would
> cause the rw snapshot being deleted and a new rw snapshot created from the
> read only one.
>
>
> Chris Murphy
>
--
Michael Chang
Software Engineer
Rm. B, 26F, No.216, Tun Hwa S. Rd., Sec.2
Taipei 106, Taiwan, R.O.C
+886223760030
address@hidden
SUSE
- Re: booting btrfs, (continued)
- Re: booting btrfs, Vladimir 'φ-coder/phcoder' Serbinenko, 2013/12/23
- Re: booting btrfs, Chris Murphy, 2013/12/24
- Re: booting btrfs, Vladimir 'φ-coder/phcoder' Serbinenko, 2013/12/24
- Re: booting btrfs, Michael Chang, 2013/12/24
- Re: booting btrfs, Andrey Borzenkov, 2013/12/24
- Re: booting btrfs, Michael Chang, 2013/12/30
- Re: booting btrfs,
Michael Chang <=
- Re: booting btrfs, Vladimir 'φ-coder/phcoder' Serbinenko, 2013/12/30
- Re: booting btrfs, Andrey Borzenkov, 2013/12/30
- Re: booting btrfs, Michael Chang, 2013/12/31
- Re: booting btrfs, Chris Murphy, 2013/12/31
- Re: booting btrfs, Michael Chang, 2013/12/30