From: Johannes Pfrang <johannespfrang@gmail.com>
To: Hugo Mills <hugo@carfax.org.uk>, linux-btrfs@vger.kernel.org
Subject: Re: Btrfs - distribute files equally across multiple devices
Date: Mon, 6 Jul 2015 20:34:56 +0200 [thread overview]
Message-ID: <559ACA50.8000304@gmail.com> (raw)
In-Reply-To: <20150706175327.GD10539@carfax.org.uk>
[-- Attachment #1: Type: text/plain, Size: 2709 bytes --]
Thank you. That's a very helpful explanation. I've just did balance
start -dconvert=single ;)
Fwiw, the best explanation about "single" I could find was in the
Glossary[1].
I don't have an account on the wiki, but your first paragraph would fit
great there!
[1] https://btrfs.wiki.kernel.org/index.php/Glossary
On 06.07.2015 19:53, Hugo Mills wrote:
> On Mon, Jul 06, 2015 at 06:22:52PM +0200, Johannes Pfrang wrote:
> Not quite. In single mode, the FS will allocate linear chunks of
> space 1 GiB in size, and use those to write into (fitting many files
> into each chunk, potentially). The chunks are allocated as needed, and
> will go on the device with the most unallocated space.
>
> So, with equal-sized devices, the first 1 GiB will go on the first
> device, the second 1 GiB on the second device, and so on.
>
> With unequal devices, you'll put data on the largest device, until
> its free space reaches the size of the next largest, and then the
> chunks will be alternated between those two, until the free space on
> each of the two largest reaches the size of the third-largest, and so
> on.
>
> (e.g. for devices sized 6 TB, 4 TB, 3 TB, the first 2 TB will go
> exclusively on the first device; the next 2 TB will go on the first
> two devices, alternating in 1 GB chunks; the rest goes across all
> three devices, again, alternating in 1 GB chunks.)
>
> This is all very well for an append-only filesystem, but if you're
> changing the files on the FS at all, there's no guarantee as to where
> the changed extents will end up -- not even on the same device, let
> alone close to the rest of the file on the platter.
>
> I did work out, some time ago, a prototype chunk allocator (the 1
> GiB-scale allocations) that would allow enough flexibility to control
> where the next chunk to be allocated would go. However, that still
> leaves the extent allocator to deal with, which is the second, and
> much harder, part of the problem.
>
> Basically, don't assume any kind of structure to the location of
> your data on the devices you have, and keep good, tested, regular
> backups of anything you can't stand to lose and can't replace. There
> are no guarantees that would let you assume easily that any one file
> is on a single device, or that anything would survive the loss of a
> device.
I promise I won't assume that.
Two 4TB data disks:
- 3TiB+3TiB data=single,meta=raid1 replaceable/unimportant
- 654Gib|654Gib data/meta=raid1 important with regular backups
efficient + safe enough (for my use-case)
>
> I'm sure this is an FAQ entry somewhere... It's come up enough
> times.
>
> Hugo.
>
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
prev parent reply other threads:[~2015-07-06 18:35 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-06 16:22 Btrfs - distribute files equally across multiple devices Johannes Pfrang
2015-07-06 16:45 ` Roman Mamedov
2015-07-06 17:31 ` Johannes Pfrang
2015-07-06 17:53 ` Hugo Mills
2015-07-06 18:34 ` Johannes Pfrang [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=559ACA50.8000304@gmail.com \
--to=johannespfrang@gmail.com \
--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.