From: Dan van der Ster <dan@vanderster.com>
To: Rich Rauenzahn <rrauenza@gmail.com>
Cc: Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: Western Digital Red's SMR and btrfs?
Date: Tue, 5 May 2020 11:30:47 +0200 [thread overview]
Message-ID: <CABZ+qqmT2==GvkD0hMFn8m=v_UYXgitcWdxbUrEEdmdbkUfwmQ@mail.gmail.com> (raw)
In-Reply-To: <CAG+QAKXuaah3tkhQLd7mD3bx+pc3JZdXkUg6yr0R8=Zv2vXnhw@mail.gmail.com>
FWIW, I've written a little tool to help incrementally, slowly,
balance an array with SMR drives:
https://gist.github.com/dvanders/c15d490ae380bcf4220a437b18a32f04
It balances 2 data chunks per iteration, and if that took longer than
some threshold (e.g. 60s), it injects an increasingly larger sleep
between subsequent iterations.
I'm just getting started with DM-SMR drives in my home array (3x 8TB
Seagates), but this script seems to be much more usable than a
one-shot full balance, which became ultra slow and made little
progress after the CMR cache filled up.
And my 2 cents: the RAID1 is quite usable for my media storage
use-case; outside of balancing I don't notice any slowness (and in
fact it maybe quicker than usual, due to the CMR cache which
sequentializes up to several gigabytes of random writes)
Cheers, Dan
On Sat, May 2, 2020 at 7:25 AM Rich Rauenzahn <rrauenza@gmail.com> wrote:
>
> Has there been any btrfs discussion off the list (I haven't seen any
> SMR/shingled mails in the archive since 2016 or so) regarding the news
> that WD's Red drives are actually SMR?
>
> I'm using these reds in my btrfs setup (which is 2-3 drives in RAID1
> configuration, not parity based RAIDs.) I had noticed that adding a
> new drive took a long time, but other than than, I haven't had any
> issues that I know of. They've lasted quite a long time, although I
> think my NAS would be considered more of a cold storage/archival.
> Photos and Videos.
>
> Is btrfs raid1 going to be the sweet spot on these drives?
>
> If I start swapping these out -- is there a recommended low power
> drive? I'd buy the red pro's, but they spin faster and produce more
> heat and noise.
>
> Rich
next prev parent reply other threads:[~2020-05-05 9:31 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-02 5:24 Western Digital Red's SMR and btrfs? Rich Rauenzahn
2020-05-04 23:08 ` Zygo Blaxell
2020-05-04 23:24 ` Chris Murphy
2020-05-05 2:00 ` Zygo Blaxell
2020-05-05 2:22 ` Chris Murphy
2020-05-05 3:26 ` Zygo Blaxell
2020-05-09 21:00 ` Phil Karn
2020-05-09 21:46 ` Steven Fosdick
2020-05-11 5:06 ` Zygo Blaxell
2020-05-11 20:35 ` Phil Karn
2020-05-11 21:13 ` Alberto Bursi
2020-05-11 22:42 ` Phil Karn
2020-05-12 0:12 ` Zygo Blaxell
2020-05-12 2:17 ` Alberto Bursi
2020-05-11 4:06 ` Damien Le Moal
2020-05-05 9:30 ` Dan van der Ster [this message]
2020-05-02 12:26 Torstein Eide
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='CABZ+qqmT2==GvkD0hMFn8m=v_UYXgitcWdxbUrEEdmdbkUfwmQ@mail.gmail.com' \
--to=dan@vanderster.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=rrauenza@gmail.com \
/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.