Shridhar Shetty posted on Tue, 17 Apr 2012 16:14:45 +0000 as excerpted:
> I have created a btrfs filesystem with RAID1 setup having 2 disks.
> Everything works fine but when I try to umount the device and remount it
> in degraded mode,
> the data still goes into both the disk. ideally in degraded mode only
> one disk show disk activity and not the failed ones.
>
> System Config:
> Base OS: Slackware kernel: linux 3.3.2
>
> "sar -pd 2 10" shows me that the data is been written/read from
both
> devices.
>
> Also, Is there any way in which I can remove the failed disk without
> adding a new one in a RAID1 (2 disk setup). The reason being we want the
> option to keep it running in degraded(single disk) mode for sometime and
> on a weekend replace the failed drive with a fresh one :-).
Are you sure you created the filesystem with raid1 mode for both data and
metadata? Some people end up with only one or the other set to raid1
mode (metadata defaults to mirroring on two-device, but data will default
to single if not specifically set).
Meanwhile, AFAIK the degraded option doesn''t force degraded, it only
allows mounting degraded if the other device is non-functional. If btrfs
detects all its devices and doesn''t detect a problem with one,
it''ll
still try to run all devices, regardless of the degraded mount-option.
Are you aware of the wiki and have you read up on multi-device btrfs
there? If not, I very strongly recommend it, as btrfs'' so-called raid1
mode isn''t really raid1, but only two-way mirroring (tho on two devices
it''s about the same, but there''s still some operational
differences
compared to say md/raid), and you really need to read up on how it works
in ordered to understand what''s going on here and how to do what you
were
intending to do.
FWIW the commands are btrfs device remove, btrfs device delete, then
btrfs device add when you get the replacement, but you really need to
read the wiki to understand the various implications.
Wiki front-page:
http://btrfs.ipv5.de/index.php?title=Main_Page
Documentation:
http://btrfs.ipv5.de/index.php?title=Main_Page#Documentation
(There''s a wiki at btrfs.wiki.kernel.org as well, but it
hasn''t been
updated since the kernel.org breakin some months ago, and is thus rather
stale by now. The above ipv5.de wiki was supposed to be temporary, but
it''s looking more and more permanent...)
Read getting started, of course, the faq, the problem faq, gotchas,
usecases, sysadminguide, and using btrfs with multiple devices, at
least. That should give you a good handle on the filesystem in general,
including what you''re dealing with. What you''re particularly
after is in
the multiple devices section, but to really understand what btrfs is
doing, I''d recommend reading or at least scanning the others as well.
Otherwise, you''ll likely miss something that could be critical at some
point.
One additional point, which you may already know, but the implications of
your question (waiting for a weekend to replace the old drive, like you
can''t afford for your btrfs to be out of service temporarily) have me
fearing that you''re not aware of it.
As you''ll see repeatedly if you read the wiki and/or this list for
long,
btrfs is still marked experimental in the kernel and under heavy
development, fit for testing only at this point. Read that as still
buggy enough to eat your data for lunch if you let it! While a good
sysadmin always has backups, on a mature filesystem, the data on the
filesystem is the primary copy, with the backups there just in case. By
contrast, the best way to think of the data on btrfs at this point is as
a throw-away testing-only copy that the filesystem can eat for lunch at
any point. If you value your data, you''ll have what you consider your
primary copy on a more mature filesystem, with the usual backups you''d
normally have of that, and the data on your testing btrfs will be just
that, testing, no big deal if it gets eaten, because it was an extra
"testing-only" copy of your data all along. Of course as a good
tester,
you''ll be running current kernels (as I see you are), and following
this
list in ordered to see the issues others are reporting and to report your
own if necessary.
We see people way too many people on this list asking for some way to
restore their data... because it was their ONLY copy or because they were
treating it as their primary copy and they allowed their backups to get
stale. Unfortunately they didn''t get the message about btrfs being
stull
experimental, still buggy, and under heavy development, until it was too
late. Let''s not have you as another example!
--
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
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html