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


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