From: Austin S Hemmelgarn <ahferroin7@gmail.com>
To: Duncan <1i5t5.duncan@cox.net>, linux-btrfs@vger.kernel.org
Subject: Re: Why subvolume and not just volume?
Date: Thu, 6 Aug 2015 07:17:46 -0400 [thread overview]
Message-ID: <55C3425A.7030802@gmail.com> (raw)
In-Reply-To: <pan$26b5e$81e797b6$ee8aa3f0$e575c51a@cox.net>
[-- Attachment #1: Type: text/plain, Size: 1066 bytes --]
On 2015-08-06 03:23, Duncan wrote:
> Martin posted on Wed, 05 Aug 2015 09:06:40 +0200 as excerpted:
>
>> [W]hat is the penalty of a subvolume compared to a directory? From a
>> design perspective, couldn't all directories just be subvolumes?
>
> In addition to the performance issues mentioned by others, there's at
> least one further practical reason as well.
>
> Snapshots stop at subvolume boundaries. It's thus quite useful to use
> subvolumes to delineate the limits of the snapshot, saying, in effect,
> snapshot this dir (which happens to be a subvol not just a normal dir)
> recursively, but don't snapshot the subtree starting with this nested
> subdir (which again is a (different) subvol).
>
And for some people, this is very useful functionality. I use it to
specifically exclude subsets of trivially reproducible data from backups
(for example, I always clone public git repositories into individual
subvolumes, and keep my local copy of the Portage tree on a separate one
(when it isn't on a separate filesystem that is)).
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]
prev parent reply other threads:[~2015-08-06 11:18 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-05 7:06 Why subvolume and not just volume? Martin
2015-08-05 7:23 ` Qu Wenruo
2015-08-05 17:13 ` David Sterba
2015-08-06 7:23 ` Duncan
2015-08-06 11:17 ` Austin S Hemmelgarn [this message]
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=55C3425A.7030802@gmail.com \
--to=ahferroin7@gmail.com \
--cc=1i5t5.duncan@cox.net \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.