From: Damien Le Moal <Damien.LeMoal@wdc.com>
To: Phil Karn <karn@ka9q.net>,
Zygo Blaxell <ce3g8jdj@umail.furryterror.org>,
Rich Rauenzahn <rrauenza@gmail.com>
Cc: Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: Western Digital Red's SMR and btrfs?
Date: Mon, 11 May 2020 04:06:00 +0000 [thread overview]
Message-ID: <BY5PR04MB69009A65502C25E208317161E7A10@BY5PR04MB6900.namprd04.prod.outlook.com> (raw)
In-Reply-To: f7ae0b64-048d-3898-6e2d-5702e2f79f47@ka9q.net
On 2020/05/10 6:01, Phil Karn wrote:
> On 5/4/20 16:08, Zygo Blaxell wrote:
>> The basic problem with DM-SMR drives is that they cache writes in CMR
>> zones for a while, but they need significant idle periods (no read or
>> write commands from the host) to move the data back to SMR zones, or
>> they run out of CMR space and throttle writes from the host.
>
> Does anybody know where the drive keeps all that metadata? On rotating
> disk, or in flash somewhere?
This is drive implementation dependent. That is not something defined by
standards. Differences will exist between vendors and models.
> Just wondering what happens when power suddenly fails during these
> rewrite operations.
The drive FW saves whatever information is needed, consistent with the drive
write cache flush state. Exactly like an SSD would do too.
>> Some kinds of RAID rebuild don't provide sufficient idle time to complete
>> the CMR-to-SMR writeback, so the host gets throttled. If the drive slows
>
> My understanding is that large sequential writes can go directly to the
> SMR areas, which is an argument for a more conventional RAID array. How
> hard does btrfs try to do large sequential writes?
"large" is not a sufficient parameter to conclude/guess on any specific
behavior. Alignment (start LBA) of the write command, sectors already written or
not, drive write cache on or off, drive write cache full or not, drive
implementation differences, etc. There are a lot more parameters influencing how
the drive will process writes. There is no simple statement that can be made
about how these drive work internally. This is completely vendor & model
dependent, exactly like SSDs FTL implementations.
--
Damien Le Moal
Western Digital Research
next prev parent reply other threads:[~2020-05-11 4:06 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 [this message]
2020-05-05 9:30 ` Dan van der Ster
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=BY5PR04MB69009A65502C25E208317161E7A10@BY5PR04MB6900.namprd04.prod.outlook.com \
--to=damien.lemoal@wdc.com \
--cc=ce3g8jdj@umail.furryterror.org \
--cc=karn@ka9q.net \
--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.