From: Steve Leung <sjleung@shaw.ca>
To: Chris Murphy <lists@colorremedies.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: safe/necessary to balance system chunks?
Date: Fri, 25 Apr 2014 12:36:20 -0600 [thread overview]
Message-ID: <535AAB24.4000206@shaw.ca> (raw)
In-Reply-To: <75D8579E-1284-4F12-A573-15D50EFC4614@colorremedies.com>
On 04/25/2014 11:24 AM, Chris Murphy wrote:
>
> On Apr 25, 2014, at 8:57 AM, Steve Leung <sjleung@shaw.ca> wrote:
>
>> I've got a 3-device RAID1 btrfs filesystem that started out life as single-device.
>>
>> btrfs fi df:
>>
>> Data, RAID1: total=1.31TiB, used=1.07TiB
>> System, RAID1: total=32.00MiB, used=224.00KiB
>> System, DUP: total=32.00MiB, used=32.00KiB
>> System, single: total=4.00MiB, used=0.00
>> Metadata, RAID1: total=66.00GiB, used=2.97GiB
>>
>> This still lists some system chunks as DUP, and not as RAID1. Does this mean that if one device were to fail, some system chunks would be unrecoverable? How bad would that be?
>
> Anyway, it's probably a high penalty for losing only 32KB of data. I think this could use some testing to try and reproduce conversions where some amount of "system" or "metadata" type chunks are stuck in DUP. This has come up before on the list but I'm not sure how it's happening, as I've never encountered it.
As for how it occurred, I'm not sure. I created this filesystem some
time ago (not sure exactly, but I'm guessing with a 3.4-era kernel?) so
it's quite possible it's not reproducible on newer kernels.
It's also nice to know I've been one failed device away from a dead
filesystem for a long time now, but better to notice it late than never. :)
Steve
prev parent reply other threads:[~2014-04-25 18:45 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-25 14:57 safe/necessary to balance system chunks? Steve Leung
2014-04-25 17:24 ` Chris Murphy
2014-04-25 18:12 ` Austin S Hemmelgarn
2014-04-25 18:43 ` Steve Leung
2014-04-25 19:07 ` Austin S Hemmelgarn
2014-04-26 4:01 ` Duncan
2014-04-26 1:11 ` Duncan
2014-04-26 1:24 ` Chris Murphy
2014-04-26 2:56 ` Steve Leung
2014-04-26 4:05 ` Chris Murphy
2014-04-26 4:55 ` Duncan
2014-04-25 19:14 ` Hugo Mills
2014-06-19 11:32 ` Alex Lyakas
2014-04-25 23:03 ` Duncan
2014-04-26 1:41 ` Chris Murphy
2014-04-26 4:23 ` Duncan
2014-04-25 18:36 ` Steve Leung [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=535AAB24.4000206@shaw.ca \
--to=sjleung@shaw.ca \
--cc=linux-btrfs@vger.kernel.org \
--cc=lists@colorremedies.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).