Re: btrfs and mdadm raid 6

[Roman Mamedov <rm@romanrm.ru>]

[-- Attachment #1: Type: text/plain, Size: 2791 bytes --]

On Mon, 20 Aug 2012 12:22:31 -0400
Curtis Jones <curtis.jones@gmail.com> wrote:

> 	1. is btrfs-convert on /dev/md0 stable/reliable/tested/not-a-stupid-thing-to-do?

btrfs-convert does not care on what kind of block device an FS resides, so it's OK.

> 	2. based on the reading I've done, resizing btrfs is supported. can you confirm?

Yes, both growing and shrinking.

> 	3. there aren't any known compatibility or other issues with running btrfs on top of mdadm (raid 6)

Not that I know of.

But... if we were a year into the future and there was working btrfs RAID6,
then that configuration (btrfs native RAID6 rather than single-device btrfs on
top of mdadm) would provide more resilience, as blocks with failed checksums
could be automatically reconstructed from 'good' data on other devices in the
array.

In the current situation though, btrfs checksums will only tell you that you
lost data due to some corruption underneath, in (unlikely)case that it
happens and mdadm lets it through.

>	4. any other caveats I might want to consider?

1) AFAIK the patch [1] is still not in the mainline, so you'll either have to
include it into your kernels yourself, or you will end up with a truly and
enormous metadata allocation size, if I'm counting correctly on your array with
42 TB of usable space you will have 840GB * 2 = 1700 GB reserved for metadata.

[1] http://comments.gmane.org/gmane.comp.file-systems.btrfs/19200

2) On filesystem converted with btrfs-convert the metadata allocation is
unnecessarily large due to some other, conversion-related reasons; but this
can be fixed with "btrfs filesystem balance -musage=5 /mount/point" (do
several runs increasing the value from 5 to 10, 20 or more, if it fails to
free up a sufficient amount of space). This will defragment metadata and free
up chunks which end up being completely unused (which will be a lot of them),
but only down to the kernel's desired minimum allocation, see point #1.

3) Due to the point #1 and in general for performance reasons, considering
also that you're already running on top of a parity-protected RAID, you might
want to consider switching the metadata profile from DUP to single (i.e. just
one copy of metadata on the device, not two).
"btrfs fi balance start -mconvert=single /mnt/point"

Regarding balance, see https://btrfs.wiki.kernel.org/index.php/Balance_Filters

> I just upgraded from kernel v3.5.1 to v3.5.2 and I have the btrfs-tools (v0.19) compiled straight from git.

You're doing great :)

Also, btw, I hope you have a full backup of everything you care about.

-- 
With respect,
Roman

~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Stallman had a printer,
with code he could not see.
So he began to tinker,
and set the software free."

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]