From: Dave Chinner <david@fromorbit.com>
To: Johannes Thumshirn <jthumshirn@suse.de>
Cc: lsf-pc@lists.linux-foundation.org, linux-block@vger.kernel.org,
linux-fsdevel@vger.kernel.org, linux-nvdimm@lists.01.org,
linux-btrfs@vger.kernel.org, hare@suse.de
Subject: Re: [LSF/MM TOPIC] Software RAID Support for NV-DIMM
Date: Sat, 16 Feb 2019 16:31:33 +1100 [thread overview]
Message-ID: <20190216053133.GT20493@dastard> (raw)
In-Reply-To: <20190215095710.GA12279@linux-x5ow.site>
On Fri, Feb 15, 2019 at 10:57:12AM +0100, Johannes Thumshirn wrote:
> (This is a joint proposal with Hannes Reinecke)
>
> Servers with NV-DIMM are slowly emerging in data centers but one key feature
> for reliability of these systems hasn't been addressed up to now, data
> redundancy.
>
> While it would be best to solve this issue in the memory controller of the CPU
> itself, I don't see this coming in the next few years. This puts us as the OS
> in the burden to create the redundant copies of data for the users.
>
> If we leave of the DAX support Linux' software RAID implementations (MD,
> device-mapper and BTRFS RAID) do already work on top of pmem devices, but they
> are incompatible with DAX.
>
> In this session Hannes and I would like to discuss eventual ways how we as an
> operating system can mitigate these issues for our users.
We've supported this since mid 2018 and commit ba23cba9b3bd ("fs:
allow per-device dax status checking for filesystems"). That is,
we can have DAX on the XFS RT device indepently of the data device.
That is, you set up pmem in three segments - two small identical
segments start get mirrored with RAID1 as the data device, and
the remainder as a block device that is dax capable set up as the
XFS realtime device. Set the RTINHERIT bit on the root directory at
mkfs time ("-d rtinherit=1") and then all the data goes to the DAX
capable realtime device, and all the metadata goes to the software
raided pmem block devices that aren't DAX capable.
Problem already solved, yes?
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2019-02-16 5:37 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-15 9:57 [LSF/MM TOPIC] Software RAID Support for NV-DIMM Johannes Thumshirn
2019-02-15 16:34 ` Dan Williams
2019-02-16 5:31 ` Dave Chinner [this message]
2019-02-16 5:39 ` Dave Chinner
2019-02-16 8:16 ` Bob Liu
2019-02-16 17:05 ` Dan Williams
2019-02-16 23:00 ` Dave Chinner
2019-02-18 10:50 ` Johannes Thumshirn
2019-02-18 18:27 ` Dan Williams
[not found] ` <d7037b76-8bbe-412d-387a-4e27db26b005@oracle.com>
2019-02-19 3:59 ` Dave Chinner
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=20190216053133.GT20493@dastard \
--to=david@fromorbit.com \
--cc=hare@suse.de \
--cc=jthumshirn@suse.de \
--cc=linux-block@vger.kernel.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-nvdimm@lists.01.org \
--cc=lsf-pc@lists.linux-foundation.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).