linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: degraded two-device btrfs raid1 (data/metadata) questions
Date: Fri, 31 May 2013 14:24:25 +0000 (UTC)	[thread overview]
Message-ID: <pan$8e5ed$b63791f$8b3cc2f5$8c662141@cox.net> (raw)

1) Suppose I mount a 2-device raid1 (data/metadata both) degraded, or 
suppose one device drops out.

2) Now, I umount (or mount -o,ro, still degraded) and mount again, not 
degraded.

Questions:

a) How can I be sure that the btrfs mounted the second time with all 
devices?

b) How do I make sure all devices are again in sync? (IOW, that dropping 
a device won't lose data/metadata.)

b1) How do I check that?

b2) What command to I run to get it that way?


The reason I'm asking is that when I tested mounting a raid1 (both data/
metadata) btrfs root filesystem from the kernel commandline, I couldn't 
get it to actually mount with rootflags=device=, until I tried degraded.

With degraded it mounted, so I looked around, running btrfs fi df, btrfs 
fi show, btrfs dev stat, etc, and from all I could see it was active with 
both devices.

So I changed a file, shutdown (mounting ro in the process, since it was 
root and thus couldn't be umounted), and restarted, this time using 
degraded on the other device in the filesystem.

Unfortunately, despite all indications I could find displaying that (I 
guessed with the remount rw), it had found the second device and it was 
no longer degraded, the change made didn't carry over to the other 
filesystem -- it still had the old file.

Reboot back to the first one and it again had the changed file.

Reboot to an alternate (reiserfs) root, mount the btrfs, and TO MY 
SURPRISE IT DIDN"T REQUIRE DEGRADED TO MOUNT, EVEN THO THE TWO DEVICES 
HAD BEEN SEPARATELY BOOTED AND THUS HAD DIFFERING DATA!!

The combined fs had the changed file, but again I shut down and mounted 
the second device (with the old file, direct from the kernel command line 
so I had to use degraded again), and again, it showed the unchanged old 
file!!

kernel/md raid works FAR more dependably than this!  I can see exactly 
which devices are there and whether they're synced from /proc/mdstat.  
Further, if I re-add a device that had fallen out of the raid, md 
automatically syncs it, no back and forth between stale and new depending 
on how I mount.

Not to mention, mounting by listing the devices on the kernel command 
line for md to assemble actually WORKS.

Meanwhile, one final thing I tried, figuring it'd detect the bad data and 
update it, a btrfs scrub.  (I think I should have used a balance, and I'm 
not sure how it would have resolved the fact that I booted each one 
separately, but I EXPECTED btrfs to refuse to mount the combined devices 
filesystem once I'd done that, and to have to do the equivalent of re-
add.)

BTW, what *IS* the equivalent of md's re-add command, if it differs from 
the above (b2)?

Unfortunately, the scrub command locked up (just the command, not the 
whole kernel).  Btrfs scrub status locked up to, as did btrfs scrub 
cancel, tho one of them I was ultimately able to kill (the other one and 
the original scrub not).

I left it that way, no visible disk activity (except that from whatever 
else I did while I was waiting), for several hours.  Finally I had to 
shutdown.

Luckily I'm still running tests and wasn't really switched to that 
filesystem yet (and I know to keep backups even when I do, since btrfs is 
still development/testing), only testing to see if I could boot it 
properly.  So not trusting that filesystem any more I did a clean 
mkfs.btrfs (on an ssd so the full discard should have cleaned up any 
loose bits) and started over.

Now, I'm setting up a minimal initramfs just to user-space mount the 
btrfs root properly so I don't have to mount it degraded.

But I'm still left wondering how I'm supposed to tell whether it's 
actually running degraded or not, and how to sync everything back up if 
so.  And I'm also wondering why btrfs even LET me mount the combined both 
devices filesystem (without using degraded) once the two devices had 
diverged, each being separately booted to rw mode so a simple resync 
shouldn't be able to work, and how it is /expected/ to handle that.

-- 
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


             reply	other threads:[~2013-05-31 14:24 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-31 14:24 Duncan [this message]
2013-06-01  3:06 ` degraded two-device btrfs raid1 (data/metadata) questions Duncan

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$8e5ed$b63791f$8b3cc2f5$8c662141@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 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).