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:39:57 +1100 [thread overview]
Message-ID: <20190216053957.GU20493@dastard> (raw)
In-Reply-To: <20190216053133.GT20493@dastard>
On Sat, Feb 16, 2019 at 04:31:33PM +1100, Dave Chinner wrote:
> 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?
Sorry, this was meant to be a reply to Dan's email commenting about
some people needing mirrored metadata, not the parent that was
talking about whole device RAID...
i.e. mirrored metadata w/ FS-DAX for data should already be a solved
problem...
Cheers,
Dave.
> Cheers,
>
> Dave.
> --
> Dave Chinner
> david@fromorbit.com
>
--
Dave Chinner
david@fromorbit.com
WARNING: multiple messages have this Message-ID (diff)
From: Dave Chinner <david@fromorbit.com>
To: Johannes Thumshirn <jthumshirn@suse.de>
Cc: linux-nvdimm@lists.01.org, linux-block@vger.kernel.org,
hare@suse.de, linux-fsdevel@vger.kernel.org,
lsf-pc@lists.linux-foundation.org, linux-btrfs@vger.kernel.org
Subject: Re: [LSF/MM TOPIC] Software RAID Support for NV-DIMM
Date: Sat, 16 Feb 2019 16:39:57 +1100 [thread overview]
Message-ID: <20190216053957.GU20493@dastard> (raw)
In-Reply-To: <20190216053133.GT20493@dastard>
On Sat, Feb 16, 2019 at 04:31:33PM +1100, Dave Chinner wrote:
> 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?
Sorry, this was meant to be a reply to Dan's email commenting about
some people needing mirrored metadata, not the parent that was
talking about whole device RAID...
i.e. mirrored metadata w/ FS-DAX for data should already be a solved
problem...
Cheers,
Dave.
> Cheers,
>
> Dave.
> --
> Dave Chinner
> david@fromorbit.com
>
--
Dave Chinner
david@fromorbit.com
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
next prev parent reply other threads:[~2019-02-16 5:40 UTC|newest]
Thread overview: 21+ 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 9:57 ` Johannes Thumshirn
2019-02-15 16:34 ` Dan Williams
2019-02-15 16:34 ` Dan Williams
2019-02-16 5:31 ` Dave Chinner
2019-02-16 5:31 ` Dave Chinner
2019-02-16 5:39 ` Dave Chinner [this message]
2019-02-16 5:39 ` Dave Chinner
2019-02-16 8:16 ` Bob Liu
2019-02-16 8:16 ` Bob Liu
2019-02-16 17:05 ` Dan Williams
2019-02-16 17:05 ` Dan Williams
2019-02-16 23:00 ` Dave Chinner
2019-02-16 23:00 ` Dave Chinner
2019-02-18 10:50 ` Johannes Thumshirn
2019-02-18 10:50 ` Johannes Thumshirn
2019-02-18 18:27 ` Dan Williams
2019-02-18 18:27 ` Dan Williams
2019-02-19 2:15 ` Jane Chu
2019-02-19 3:59 ` Dave Chinner
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=20190216053957.GU20493@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 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.