From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: Is it safe to use btrfs on top of different types of devices?
Date: Sun, 15 Oct 2017 12:05:20 +0000 (UTC) [thread overview]
Message-ID: <pan$ab30f$50fa7dd5$4020df3f$7f597abb@cox.net> (raw)
In-Reply-To: CAGtRCvfqUP_79cKC_Rzs6MD_uZiVbjt9QW0_BeOpACN_c3ev5w@mail.gmail.com
Zoltán Ivánfi posted on Sun, 15 Oct 2017 10:30:52 +0200 as excerpted:
> You assumed correctly that what I really wanted to ask about was btrfs
> on SATA+USB, thanks for answering that questions as well. Based on your
> replies I feel assured that btrfs should not be affected by this
> particular issue due to operating on the filesystem level and not on the
> block device level; but USB connectivity issues can still lead to
> problems.
>
> Do these USB connectivity issues lead to data corruption? Naturally for
> raid0 they will, but for raid1 I suppose they shouldn't as one copy of
> the data remains intact.
FWIW, the problems I've /personally/ had with raid1 here, on both mdraid
and btrfs raid, 100% SATA connections on both, with older SATA-1 spinning
rust for the mdraid, and newer SSDs for btrfs raid, have to do with
suspend to RAM, or hibernate (suspend to disk). I finally gave up on
it. The problem is that in resume, one device is inevitably slower than
the others to come back up, and will often get kicked from the array.
On original bootup there's a mechanism that waits for all devices, but
apparently it's not activated on resume from suspend-to-RAM. With mdraid
(longer ago, with a machine that would hibernate but not suspend to ram)
the device can be readded and will resync. Btrfs (as of a couple years
ago anyway, with a machine that would suspend to RAM but I've not
actually tried hibernate as I've not configured a swap partition to
suspend to) remains a bit behind in that area, however, and the slow
device remains unsynced, eventually forcing a full reboot, where it comes
up with the raid, but still must be manually synced via a btrfs scrub.
Since I end up having to reboot and do a manual sync anyway, it's simply
not worth doing suspend-to-ram in the first place, and I've started just
shutting down or leaving the machine running. That seems to work much
better for both cases.
I've not personally tried raid1 (of either btrfs or mdraid) on USB, so I
have no personal experience there, but as I said, we do get more reports
of problems with USB-connected btrfs raid, than with SATA. Most of the
problems are fixable, and the reports have lessened as btrfs has matured,
but I'd not recommend it or consider it worth the hassle.
What I'd recommend instead, if USB connectivity is all that's available
(as with many appliance-type machines, my router, for instance, tho I'm
not actually using the feature there), is larger capacity, then use btrfs
in dup mode so it gets to use btrfs checksumming not just for error
detection, but correction as well (a big advantage of both raid1 and dup
mode), and do actual backups to other devices. (Btrfs send/receive can
be used for the backups, tho here I just alternate backups and use a
simpler mkfs and midnight-commander copying with btrfs lzo compression.)
I tend to heavily partition and use smaller, independent btrfs anyway,
over the huge multi-TB single btrfs that other people seem to favor, so a
4 TB single device in dup mode for 2 TB capacity is larger by an order of
magnitude than any of my filesystems (I'd certainly partition up anything
that big, even for dup mode), tho I can imagine a 4 TB device in dup mode
for 2 TB capacity would cramp the style of some users.
--
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
next prev parent reply other threads:[~2017-10-15 12:05 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-14 19:00 Is it safe to use btrfs on top of different types of devices? Zoltán Ivánfi
2017-10-15 0:19 ` Peter Grandi
2017-10-15 3:42 ` Duncan
2017-10-15 8:30 ` Zoltán Ivánfi
2017-10-15 12:05 ` Duncan [this message]
2017-10-16 11:53 ` Austin S. Hemmelgarn
2017-10-16 16:57 ` Zoltan
2017-10-16 17:27 ` Austin S. Hemmelgarn
2017-10-17 1:14 ` Adam Borowski
2017-10-17 11:26 ` Austin S. Hemmelgarn
2017-10-17 11:42 ` Zoltan
2017-10-17 12:40 ` Austin S. Hemmelgarn
2017-10-17 17:06 ` Adam Borowski
2017-10-17 19:19 ` Austin S. Hemmelgarn
2017-10-17 20:21 ` Adam Borowski
2017-10-17 21:56 ` Zoltán Ivánfi
2017-10-18 4:44 ` Duncan
2017-10-18 14:07 ` Peter Grandi
2017-10-18 11:30 ` Austin S. Hemmelgarn
2017-10-18 11:59 ` Adam Borowski
2017-10-18 14:30 ` Austin S. Hemmelgarn
2017-10-18 4:50 ` Duncan
2017-10-18 13:53 ` Peter Grandi
2017-10-18 14:30 ` Austin S. Hemmelgarn
2017-10-19 11:01 ` Peter Grandi
2017-10-19 12:32 ` Austin S. Hemmelgarn
2017-10-19 18:39 ` Peter Grandi
2017-10-20 11:53 ` Austin S. Hemmelgarn
2017-10-19 13:48 ` Zoltan
2017-10-19 14:27 ` Austin S. Hemmelgarn
2017-10-19 14:42 ` Zoltan
2017-10-19 15:07 ` Austin S. Hemmelgarn
2017-10-19 18:00 ` Peter Grandi
2017-10-19 17:56 ` Peter Grandi
2017-10-19 18:59 ` Peter Grandi
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$ab30f$50fa7dd5$4020df3f$7f597abb@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).