From: "Andreas Buschka" <a.buschka@tarent.de>
To: <linux-btrfs@vger.kernel.org>
Subject: AW: Why subvolumes?
Date: Tue, 23 Jul 2013 16:52:38 +0200 [thread overview]
Message-ID: <01ff01ce87b4$46b7d980$d4278c80$@tarent.de> (raw)
In-Reply-To: <CA+V+5QrNAo_RVEiONHRqkN5O89jgtoFDecuWnu41_ovJmLVhuA@mail.gmail.com>
Hi Jerome,
essentially, a btrfs sub volume is the root of a btrfs (you can take it and mount it as it is). This is critical for the snapshot functionality: If you have a sub volume (consisting of a snapshot) for, say, "/", and your system goes south (e.g. after updating the kernel or another crucial system package), then all you have to do it tell the Linux kernel at the bootloader prompt (via the rootflags=... parameter) not to mount the default btrfs, but the snapshot. Then, you can boot the "last known good" state of the system normally and recover from the comfort of a running system.
The main point here is that the default btrfs "sub volume" (which you would normally mount as /) is technically not different from any other sub volume at all.
Best regards,
Andreas
-----Ursprüngliche Nachricht-----
Von: linux-btrfs-owner@vger.kernel.org [mailto:linux-btrfs-owner@vger.kernel.org] Im Auftrag von Jerome Haltom
Gesendet: Dienstag, 23. Juli 2013 14:00
An: Linux Btrfs
Betreff: Q: Why subvolumes?
May I ask why the decision to implement snapshotting through subvolumes? I've been very curious about why the design wasn't to simply allow snapshotting of any directory or file.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2013-07-23 15:00 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-23 11:59 Q: Why subvolumes? Jerome Haltom
2013-07-23 14:52 ` Andreas Buschka [this message]
2013-07-23 15:06 ` Hugo Mills
2013-07-23 17:47 ` Gabriel de Perthuis
2013-07-23 19:30 ` Hugo Mills
2013-07-23 19:41 ` Gabriel de Perthuis
2013-07-23 19:43 ` Jerome Haltom
2013-07-23 21:52 ` Chris Murphy
2013-07-23 23:39 ` Jerome Haltom
2013-07-24 1:27 ` Josef Bacik
2013-07-24 2:02 ` Chris Murphy
2013-08-04 14:56 ` Alexandre Oliva
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='01ff01ce87b4$46b7d980$d4278c80$@tarent.de' \
--to=a.buschka@tarent.de \
--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;
as well as URLs for NNTP newsgroup(s).