From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: [Docs]? Only one Subvolume with DUP (or different parameters)?
Date: Wed, 17 Feb 2016 04:49:37 +0000 (UTC) [thread overview]
Message-ID: <pan$17e03$37c598a8$93a246ff$ae65c0fd@cox.net> (raw)
In-Reply-To: 56C377BB.9020101@knebb.de
Christian Völker posted on Tue, 16 Feb 2016 20:25:47 +0100 as excerpted:
> sorry for the simple question and I assume every developer here laughs
> about this question.
>
> Anyway:
>
> I have read loads of documents but did not find an answer for sure. Even
> though I assume I am right.
>
> On a btrfs filesystem created; is it possible to have subvolumes with
> data duplication and another subvolume without (resp. with just metadata
> duplication)?
>
> I have some large filesystems currently with ext4 and I am thinking of
> changing to btrfs. Some of the data is more important than others. So I
> want to have data duplication on the important files (sorted in a mount
> point) and without for the other subvolume.
>
> So I want to have the advantage of redundancy of important files
> combined with the flexibility of the volume manager and shared disk
> space.
As Hugo mentions, that's not possible at this point, tho the plan is to
make replication mode a per-subvolume or even per-file property at some
still-future point. Given the rate of progress, however, that future
point is extremely likely to be at least two years out and could well be 5
+ years out -- IOW, it's nothing you could plan for at this point.
However, it's quite possible to do multiple separate btrfs, with each one
having its own replication mode. That is, in fact, what I do here, tho
in my case it's more to keep all my data eggs from being in the same
filesystem basket, in case btrfs decides to eat a filesystem, than it is
for different replication (most of mine are raid1 across partitions on
two devices). If the filesystem goes, being on a different subvolume
from whatever triggered the problem isn't going to help much, while being
on a different filesystem entirely, which might have been mounted
read-only or not even mounted at all at the time, very likely will, and I
prefer not having all my data eggs in the same filesystem basket,
particularly when that filesystem basket is btrfs, which while
stabilizing, isn't yet full stable and mature yet, even if it means a bit
more hands-on administration than would simply shoving everything in the
same basket and hoping the bottom doesn't drop out of it.
Tho that might be just me...
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
next prev parent reply other threads:[~2016-02-17 4:49 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-16 19:25 [Docs]? Only one Subvolume with DUP (or different parameters)? Christian Völker
2016-02-16 19:46 ` Hugo Mills
2016-02-17 4:49 ` Duncan [this message]
2016-02-17 12:15 ` Austin S. Hemmelgarn
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='pan$17e03$37c598a8$93a246ff$ae65c0fd@cox.net' \
--to=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.