From: Phillip Susi <psusi@cfl.rr.com>
To: dima <dolenin@parallels.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: Snapshot rollback
Date: Mon, 24 Oct 2011 20:45:04 -0400 [thread overview]
Message-ID: <4EA60690.7080401@cfl.rr.com> (raw)
In-Reply-To: <loom.20111024T071806-3@post.gmane.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 10/24/2011 01:45 AM, dima wrote:
> Hello Phillip,
> It is hard to judge without seeing your fstab and bootloader config. Maybe your
> / was directly in subvolid=0 without creating a separate subvolume for it (like
> __active in Goffredo's reply)? In my very humble opinion, if you have your @home
> subvolume under subvolid=0 and then change the default subvolume, it just cannot
> access your @home any more.
Why can't it?
It appears that Ubuntu sets up two subvols, one named @ and one named
@home, and mounts them at / and /home respectively. The boot loader was
set to pass rootflags=subvol=@. After changing the default volume, the
system would not boot until I removed that rootflags argument, then it
mounted the snapshot correctly as the root, but refused to mount /home,
giving this nonsense error that /dev/sda1 is not a valid block device.
> Here is a very good article that explains the working of subvolumes. I used it
> as reference a lot.
> http://www.funtoo.org/wiki/BTRFS_Fun#Using_snapshots_for_system_recovery_.28aka_Back_to_the_Future.29
This advice seems completely goofy. It tells you to change the default
subvol and boot from the snapshot, but then to have rsync copy all of
the files back to the default volume, then switch back to using that.
This seems to defeat the entire purpose. If you are already booting
from the snapshot, why would you want to waste time copying the files
back to the original subvol instead of just deleting it, and using the
snapshot volume from now on?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6mBo4ACgkQJ4UciIs+XuK+wgCeOD0km3GpdseQ0h4y0FKSI7JS
xC0An2JqA4aOHCkZ7+g+TORunVnpmQj7
=6KKf
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2011-10-25 0:45 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-23 19:42 Snapshot rollback Phillip Susi
2011-10-23 20:35 ` Goffredo Baroncelli
2011-10-24 5:45 ` dima
2011-10-24 5:58 ` Fajar A. Nugraha
2011-10-24 8:24 ` dima
2011-10-24 12:11 ` Fajar A. Nugraha
2011-10-25 2:00 ` dima
2011-10-25 8:01 ` Fajar A. Nugraha
2011-10-25 8:54 ` dima
2011-10-25 9:01 ` Fajar A. Nugraha
2011-10-25 0:45 ` Phillip Susi [this message]
2011-10-25 2:04 ` Arand Nash
2011-10-26 1:30 ` Phillip Susi
-- strict thread matches above, loose matches on Subject: below --
2019-07-05 10:38 snapshot rollback Ulli Horlacher
2019-07-05 11:06 ` Ulli Horlacher
2019-07-05 11:47 ` Remi Gauvin
2019-07-05 13:03 ` Graham Cobb
2019-07-05 21:18 ` Chris Murphy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4EA60690.7080401@cfl.rr.com \
--to=psusi@cfl.rr.com \
--cc=dolenin@parallels.com \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox