From: Marc Lehmann <schmorp@schmorp.de>
To: Hugo Mills <hugo@carfax.org.uk>, linux-btrfs@vger.kernel.org
Subject: Re: questoin about Data=single on multi-device fs
Date: Mon, 27 Apr 2020 13:29:47 +0200 [thread overview]
Message-ID: <20200427112946.GA3648@schmorp.de> (raw)
In-Reply-To: <20200426102547.GM32577@savella.carfax.org.uk>
On Sun, Apr 26, 2020 at 11:25:47AM +0100, Hugo Mills <hugo@carfax.org.uk> wrote:
> > The reason I chose data=single was specifically to help in case of device
> > loss at the cost of performance.
>
> Make backups. That's the only way to be sure about this sort of thing.
I think you are unthinkingly repeating a wrong (and slightly dangerous)
claim - backups cannot actually do that sort of thing: a raid will protect
against (some amount of) disk failures with no data loss, but backups
cannot: Backups can protect against complete data loss, but cannot
completely protect against data loss.
> With single data, *chunk allocation* will go to the device with the
> largest amount of unallocated space. If your data is WORM
That is definitely not the case with 5.4 - I added two disks to an
existing filesystem and copied 8TB onto it with btrfs receive, resulting
in about 3800G used on both new disks, with Data=single. I repeated it by
creating a 5 disk-fs and 1TB of data and got prettyx even distribution.
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / schmorp@schmorp.de
-=====/_/_//_/\_,_/ /_/\_\
next prev parent reply other threads:[~2020-04-27 11:29 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-26 10:04 questoin about Data=single on multi-device fs Marc Lehmann
2020-04-26 10:25 ` Hugo Mills
2020-04-27 11:29 ` Marc Lehmann [this message]
2020-04-27 11:44 ` Roman Mamedov
2020-04-27 12:32 ` Marc Lehmann
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=20200427112946.GA3648@schmorp.de \
--to=schmorp@schmorp.de \
--cc=hugo@carfax.org.uk \
--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.