From: Psalle <psalleetsile@gmail.com>
To: Alphazo <alphazo@gmail.com>, linux-btrfs@vger.kernel.org
Subject: Re: Purposely using btrfs RAID1 in degraded mode ?
Date: Tue, 5 Jan 2016 17:34:00 +0100 [thread overview]
Message-ID: <568BF078.8060303@gmail.com> (raw)
In-Reply-To: <CAHJqNbyXUfzscHteqrQtxJdYKToDNv7_Hw9tVpPuNJYwe=NHxw@mail.gmail.com>
Hello Alphazo,
I am a mere btrfs user, but given the discussions I regularly see here
about difficulties with degraded filesystems I wouldn't rely on this
(yet?) as a regular work strategy, even if it's supposed to work.
If you're familiar with git, perhaps git-annex could be an alternative.
-Psalle.
On 04/01/16 18:00, Alphazo wrote:
> Hello,
>
> My picture library today lies on an external hard drive that I sync on
> a regular basis with a couple of servers and other external drives.
> I'm interested by the on-the-fly checksum brought by btrfs and would
> like to get your opinion on the following unusual use case that I have
> tested:
> - Create a btrfs with the two drives with RAID1
> - When at home I can work with the two drives connected so I can enjoy
> the self-healing feature if a bit goes mad so I only backup perfect
> copies to my backup servers.
> - When not at home I only bring one external drive and manually mount
> it in degraded mode so I can continue working on my pictures while
> still having checksum error detection (but not correction).
> - When coming back home I can plug-back the seconde drive and initiate
> a scrub or balance to get the second drive duplicated.
>
> I have tested the above use case with a couple of USB flash drive and
> even used btrfs over dm-crypt partitions and it seemed to work fine
> but I wanted to get some advices from the community if this is really
> a bad practice that should not be used on the long run. Is there any
> limitation/risk to read/write to/from a degraded filesystem knowing it
> will be re-synced later?
>
> Thanks
> alphazo
>
> PS: I have also investigated the RAID1 on a single drive with two
> partitions but I cannot afford the half capacity resulting from that
> approach.
> --
> 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
next prev parent reply other threads:[~2016-01-05 16:34 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-04 17:00 Purposely using btrfs RAID1 in degraded mode ? Alphazo
2016-01-04 17:41 ` Chris Murphy
2016-01-06 12:30 ` Alphazo
2016-01-09 10:08 ` Duncan
2016-01-11 22:17 ` Alphazo
2016-01-05 16:34 ` Psalle [this message]
2016-01-06 12:34 ` Alphazo
2016-01-07 12:57 ` Psalle
2016-01-07 13:09 ` Alphazo
2016-01-07 17:34 ` Sree Harsha Totakura
2016-01-11 14:25 ` Psalle
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=568BF078.8060303@gmail.com \
--to=psalleetsile@gmail.com \
--cc=alphazo@gmail.com \
--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.