From: "Verma, Vishal L" <vishal.l.verma@intel.com>
To: "hch@infradead.org" <hch@infradead.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
"xfs@oss.sgi.com" <xfs@oss.sgi.com>,
"linux-nvdimm@ml01.01.org" <linux-nvdimm@ml01.01.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"viro@zeniv.linux.org.uk" <viro@zeniv.linux.org.uk>,
"Williams, Dan J" <dan.j.williams@intel.com>,
"axboe@fb.com" <axboe@fb.com>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
"linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>,
"david@fromorbit.com" <david@fromorbit.com>,
"jack@suse.cz" <jack@suse.cz>, "matthew@wil.cx" <matthew@wil.cx>
Subject: Re: [PATCH v4 5/7] fs: prioritize and separate direct_io from dax_io
Date: Sun, 8 May 2016 18:42:37 +0000 [thread overview]
Message-ID: <1462732956.3006.4.camel@intel.com> (raw)
In-Reply-To: <20160508090115.GE15458@infradead.org>
T24gU3VuLCAyMDE2LTA1LTA4IGF0IDAyOjAxIC0wNzAwLCBoY2hAaW5mcmFkZWFkLm9yZyB3cm90
ZToNCj4gT24gVGh1LCBNYXkgMDUsIDIwMTYgYXQgMDk6NDU6MDdQTSArMDAwMCwgVmVybWEsIFZp
c2hhbCBMIHdyb3RlOg0KPiA+IA0KPiA+IEknbSBub3Qgc3VyZSBJIGNvbXBsZXRlbHkgdW5kZXJz
dGFuZCBob3cgdGhpcyB3aWxsIHdvcms/IENhbiB5b3UNCj4gPiBleHBsYWluDQo+ID4gYSBiaXQ/
IFdvdWxkIHdlIGhhdmUgdG8gZXhwb3J0IHJ3X2J5dGVzIHVwIHRvIGxheWVycyBhYm92ZSB0aGUg
cG1lbQ0KPiA+IGRyaXZlcj8gV2hlcmUgZG9lcyBnZXRfdXNlcl9wYWdlcyBjb21lIGluPw0KPiBB
IERBWCBmaWxlc3lzdGVtIGNhbiBkaXJlY3RseSB1c2UgdGhlIG52ZGltbSBsYXllciB0aGUgc2Ft
ZSB3YXkgYnR0DQo+IGRvZSxzIHdoYXQncyB0aGUgcHJvYmxlbT8NCg0KVGhlIEJUVCBkb2VzIHJ3
X2J5dGVzIHRocm91Z2ggYW4gaW50ZXJuYWwtdG8tbGlibnZkaW1tIG1lY2hhbmlzbSwgYnV0DQpy
d19ieXRlcyBpc24ndCBleHBvcnRlZCB0byB0aGUgZmlsZXN5c3RlbSwgY3VycmVudGx5Li4gVG8g
ZG8gdGhpcyB3ZSdkDQpoYXZlIHRvIGVpdGhlciBhZGQgYW4gcndfYnl0ZXMgdG8gYmxvY2sgZGV2
aWNlIG9wZXJhdGlvbnMuLi5vcg0Kc29tZXRoaW5nLg0KDQpBbm90aGVyIHRoaW5nIGlzIHJ3X2J5
dGVzIGN1cnJlbnRseSBkb2Vzbid0IGRvIGVycm9yIGNsZWFyaW5nIGVpdGhlci4NCldlIHN0b3Jl
IGJhZGJsb2NrcyBhdCBzZWN0b3IgZ3JhbnVsYXJpdHksIGFuZCBsaWtlIERhbiBzYWlkIGVhcmxp
ZXIsDQp0aGF0IGhpZGVzIHRoZSBjbGVhcl9lcnJvciBhbGlnbm1lbnQgcmVxdWlyZW1lbnRzIGFu
ZCB1cHBlciBsYXllcnMNCmRvbid0IGhhdmUgdG8gYmUgYXdhcmUgb2YgaXQuIFRvIG1ha2Ugcndf
Ynl0ZXMgY2xlYXIgc3ViLXNlY3RvciBlcnJvcnMsDQp3ZSdkIGhhdmUgdG8gY2hhbmdlIHRoZSBn
cmFudWxhcml0eSBvZiBiYWQtYmxvY2tzLCBhbmQgbWFrZSB1cHBlcg0KbGF5ZXJzIGF3YXJlIG9m
IHRoZSBjbGVhcmluZyBhbGlnbm1lbnQgcmVxdWlyZW1lbnRzLg0KDQpVc2luZyBhIGJsb2NrLXdy
aXRlIHNlbWFudGljIGZvciBjbGVhcmluZyBoaWRlcyBhbGwgdGhpcyBhd2F5Lg0KDQo+IA0KPiBS
ZSBnZXRfdXNlcl9wYWdlcyBteSBpZGVhIHdhcyB0byBzaW1wbHkgdXNlIHRoYXQgdG8gbG9jayBk
b3duIHRoZQ0KPiB1c2VyDQo+IHBhZ2VzIHNvIHRoYXQgd2UgY2FuIGNhbGwgcndfYnl0ZXMgb24g
aXQuwqDCoEhvdyBlbHNlIHdvdWxkIHlvdSBkbw0KPiBpdD/CoMKgRG8NCj4gYSBrbWFsbG9jLCBj
b3B5X2Zyb21fdXNlciBhbmQgdGhlbiBhbm90aGVyIG1lbWNweT8=
WARNING: multiple messages have this Message-ID (diff)
From: "Verma, Vishal L" <vishal.l.verma@intel.com>
To: "hch@infradead.org" <hch@infradead.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
"xfs@oss.sgi.com" <xfs@oss.sgi.com>,
"linux-nvdimm@ml01.01.org" <linux-nvdimm@ml01.01.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"viro@zeniv.linux.org.uk" <viro@zeniv.linux.org.uk>,
"Williams, Dan J" <dan.j.williams@intel.com>,
"axboe@fb.com" <axboe@fb.com>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
"linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>,
"david@fromorbit.com" <david@fromorbit.com>,
"jack@suse.cz" <jack@suse.cz>,
"matthew@wil.cx" <matthew@freeurl.abc188.com>
Subject: Re: [PATCH v4 5/7] fs: prioritize and separate direct_io from dax_io
Date: Sun, 8 May 2016 18:42:37 +0000 [thread overview]
Message-ID: <1462732956.3006.4.camel@intel.com> (raw)
In-Reply-To: <20160508090115.GE15458@infradead.org>
On Sun, 2016-05-08 at 02:01 -0700, hch@infradead.org wrote:
> On Thu, May 05, 2016 at 09:45:07PM +0000, Verma, Vishal L wrote:
> >
> > I'm not sure I completely understand how this will work? Can you
> > explain
> > a bit? Would we have to export rw_bytes up to layers above the pmem
> > driver? Where does get_user_pages come in?
> A DAX filesystem can directly use the nvdimm layer the same way btt
> doe,s what's the problem?
The BTT does rw_bytes through an internal-to-libnvdimm mechanism, but
rw_bytes isn't exported to the filesystem, currently.. To do this we'd
have to either add an rw_bytes to block device operations...or
something.
Another thing is rw_bytes currently doesn't do error clearing either.
We store badblocks at sector granularity, and like Dan said earlier,
that hides the clear_error alignment requirements and upper layers
don't have to be aware of it. To make rw_bytes clear sub-sector errors,
we'd have to change the granularity of bad-blocks, and make upper
layers aware of the clearing alignment requirements.
Using a block-write semantic for clearing hides all this away.
>
> Re get_user_pages my idea was to simply use that to lock down the
> user
> pages so that we can call rw_bytes on it. How else would you do
> it? Do
> a kmalloc, copy_from_user and then another memcpy?
WARNING: multiple messages have this Message-ID (diff)
From: "Verma, Vishal L" <vishal.l.verma@intel.com>
To: "hch@infradead.org" <hch@infradead.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
"xfs@oss.sgi.com" <xfs@oss.sgi.com>,
"linux-nvdimm@ml01.01.org" <linux-nvdimm@ml01.01.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"viro@zeniv.linux.org.uk" <viro@zeniv.linux.org.uk>,
"Williams, Dan J" <dan.j.williams@intel.com>,
"axboe@fb.com" <axboe@fb.com>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
"linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>,
"david@fromorbit.com" <david@fromorbit.com>,
"jack@suse.cz" <jack@suse.cz>, "matthew@wil.cx" <matthew@wil.cx>
Subject: Re: [PATCH v4 5/7] fs: prioritize and separate direct_io from dax_io
Date: Sun, 8 May 2016 18:42:37 +0000 [thread overview]
Message-ID: <1462732956.3006.4.camel@intel.com> (raw)
In-Reply-To: <20160508090115.GE15458@infradead.org>
On Sun, 2016-05-08 at 02:01 -0700, hch@infradead.org wrote:
> On Thu, May 05, 2016 at 09:45:07PM +0000, Verma, Vishal L wrote:
> >
> > I'm not sure I completely understand how this will work? Can you
> > explain
> > a bit? Would we have to export rw_bytes up to layers above the pmem
> > driver? Where does get_user_pages come in?
> A DAX filesystem can directly use the nvdimm layer the same way btt
> doe,s what's the problem?
The BTT does rw_bytes through an internal-to-libnvdimm mechanism, but
rw_bytes isn't exported to the filesystem, currently.. To do this we'd
have to either add an rw_bytes to block device operations...or
something.
Another thing is rw_bytes currently doesn't do error clearing either.
We store badblocks at sector granularity, and like Dan said earlier,
that hides the clear_error alignment requirements and upper layers
don't have to be aware of it. To make rw_bytes clear sub-sector errors,
we'd have to change the granularity of bad-blocks, and make upper
layers aware of the clearing alignment requirements.
Using a block-write semantic for clearing hides all this away.
>
> Re get_user_pages my idea was to simply use that to lock down the
> user
> pages so that we can call rw_bytes on it. How else would you do
> it? Do
> a kmalloc, copy_from_user and then another memcpy?
WARNING: multiple messages have this Message-ID (diff)
From: "Verma, Vishal L" <vishal.l.verma@intel.com>
To: "hch@infradead.org" <hch@infradead.org>
Cc: "axboe@fb.com" <axboe@fb.com>, "jack@suse.cz" <jack@suse.cz>,
"matthew@wil.cx" <matthew@wil.cx>,
"linux-nvdimm@ml01.01.org" <linux-nvdimm@ml01.01.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"xfs@oss.sgi.com" <xfs@oss.sgi.com>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"viro@zeniv.linux.org.uk" <viro@zeniv.linux.org.uk>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
"Williams, Dan J" <dan.j.williams@intel.com>,
"linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>
Subject: Re: [PATCH v4 5/7] fs: prioritize and separate direct_io from dax_io
Date: Sun, 8 May 2016 18:42:37 +0000 [thread overview]
Message-ID: <1462732956.3006.4.camel@intel.com> (raw)
In-Reply-To: <20160508090115.GE15458@infradead.org>
On Sun, 2016-05-08 at 02:01 -0700, hch@infradead.org wrote:
> On Thu, May 05, 2016 at 09:45:07PM +0000, Verma, Vishal L wrote:
> >
> > I'm not sure I completely understand how this will work? Can you
> > explain
> > a bit? Would we have to export rw_bytes up to layers above the pmem
> > driver? Where does get_user_pages come in?
> A DAX filesystem can directly use the nvdimm layer the same way btt
> doe,s what's the problem?
The BTT does rw_bytes through an internal-to-libnvdimm mechanism, but
rw_bytes isn't exported to the filesystem, currently.. To do this we'd
have to either add an rw_bytes to block device operations...or
something.
Another thing is rw_bytes currently doesn't do error clearing either.
We store badblocks at sector granularity, and like Dan said earlier,
that hides the clear_error alignment requirements and upper layers
don't have to be aware of it. To make rw_bytes clear sub-sector errors,
we'd have to change the granularity of bad-blocks, and make upper
layers aware of the clearing alignment requirements.
Using a block-write semantic for clearing hides all this away.
>
> Re get_user_pages my idea was to simply use that to lock down the
> user
> pages so that we can call rw_bytes on it. How else would you do
> it? Do
> a kmalloc, copy_from_user and then another memcpy?
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2016-05-08 18:42 UTC|newest]
Thread overview: 144+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-28 21:16 [PATCH v4 0/7] dax: handling media errors Vishal Verma
2016-04-28 21:16 ` Vishal Verma
2016-04-28 21:16 ` Vishal Verma
2016-04-28 21:16 ` [PATCH v4 1/7] block, dax: pass blk_dax_ctl through to drivers Vishal Verma
2016-04-28 21:16 ` Vishal Verma
2016-04-28 21:16 ` Vishal Verma
2016-04-28 21:16 ` [PATCH v4 2/7] dax: fallback from pmd to pte on error Vishal Verma
2016-04-28 21:16 ` Vishal Verma
2016-04-28 21:16 ` Vishal Verma
2016-04-28 21:16 ` [PATCH v4 3/7] dax: enable dax in the presence of known media errors (badblocks) Vishal Verma
2016-04-28 21:16 ` Vishal Verma
2016-04-28 21:16 ` Vishal Verma
2016-04-28 21:16 ` Vishal Verma
2016-04-28 21:16 ` [PATCH v4 4/7] dax: use sb_issue_zerout instead of calling dax_clear_sectors Vishal Verma
2016-04-28 21:16 ` Vishal Verma
2016-04-28 21:16 ` Vishal Verma
2016-04-28 21:16 ` Vishal Verma
2016-04-28 21:16 ` [PATCH v4 5/7] fs: prioritize and separate direct_io from dax_io Vishal Verma
2016-04-28 21:16 ` Vishal Verma
2016-04-28 21:16 ` Vishal Verma
2016-04-28 21:16 ` Vishal Verma
2016-04-28 21:16 ` Vishal Verma
2016-05-02 14:56 ` Christoph Hellwig
2016-05-02 14:56 ` Christoph Hellwig
2016-05-02 14:56 ` Christoph Hellwig
2016-05-02 14:56 ` Christoph Hellwig
2016-05-02 15:45 ` Vishal Verma
2016-05-02 15:45 ` Vishal Verma
2016-05-02 15:45 ` Vishal Verma
2016-05-02 15:45 ` Vishal Verma
2016-05-02 15:45 ` Vishal Verma
2016-05-02 15:41 ` Boaz Harrosh
2016-05-02 15:41 ` Boaz Harrosh
2016-05-02 15:41 ` Boaz Harrosh
2016-05-02 15:41 ` Boaz Harrosh
2016-05-02 15:41 ` Boaz Harrosh
2016-05-02 15:51 ` Vishal Verma
2016-05-02 15:51 ` Vishal Verma
2016-05-02 15:51 ` Vishal Verma
2016-05-02 15:51 ` Vishal Verma
2016-05-02 15:51 ` Vishal Verma
2016-05-02 15:51 ` Vishal Verma
2016-05-02 16:03 ` Boaz Harrosh
2016-05-02 16:03 ` Boaz Harrosh
2016-05-02 16:03 ` Boaz Harrosh
2016-05-02 16:03 ` Boaz Harrosh
2016-05-02 16:03 ` Boaz Harrosh
2016-05-02 18:52 ` Verma, Vishal L
2016-05-02 18:52 ` Verma, Vishal L
2016-05-02 18:52 ` Verma, Vishal L
2016-05-02 18:52 ` Verma, Vishal L
2016-05-02 18:52 ` Verma, Vishal L
2016-05-02 16:01 ` Dan Williams
2016-05-02 16:01 ` Dan Williams
2016-05-02 16:01 ` Dan Williams
2016-05-02 16:01 ` Dan Williams
2016-05-02 16:01 ` Dan Williams
2016-05-02 16:22 ` Boaz Harrosh
2016-05-02 16:22 ` Boaz Harrosh
2016-05-02 16:22 ` Boaz Harrosh
2016-05-02 16:22 ` Boaz Harrosh
2016-05-02 16:22 ` Boaz Harrosh
2016-05-02 16:49 ` Dan Williams
2016-05-02 16:49 ` Dan Williams
2016-05-02 16:49 ` Dan Williams
2016-05-02 16:49 ` Dan Williams
2016-05-02 16:49 ` Dan Williams
2016-05-02 17:44 ` Boaz Harrosh
2016-05-02 17:44 ` Boaz Harrosh
2016-05-02 17:44 ` Boaz Harrosh
2016-05-02 17:44 ` Boaz Harrosh
2016-05-02 17:44 ` Boaz Harrosh
2016-05-02 18:10 ` Dan Williams
2016-05-02 18:10 ` Dan Williams
2016-05-02 18:10 ` Dan Williams
2016-05-02 18:10 ` Dan Williams
2016-05-02 18:10 ` Dan Williams
2016-05-02 18:32 ` Boaz Harrosh
2016-05-02 18:32 ` Boaz Harrosh
2016-05-02 18:32 ` Boaz Harrosh
2016-05-02 18:32 ` Boaz Harrosh
2016-05-02 18:48 ` Dan Williams
2016-05-02 18:48 ` Dan Williams
2016-05-02 18:48 ` Dan Williams
2016-05-02 18:48 ` Dan Williams
2016-05-02 18:48 ` Dan Williams
2016-05-02 19:22 ` Boaz Harrosh
2016-05-02 19:22 ` Boaz Harrosh
2016-05-02 19:22 ` Boaz Harrosh
2016-05-02 19:22 ` Boaz Harrosh
2016-05-02 19:22 ` Boaz Harrosh
2016-05-05 14:24 ` Christoph Hellwig
2016-05-05 14:24 ` Christoph Hellwig
2016-05-05 14:24 ` Christoph Hellwig
2016-05-05 14:24 ` Christoph Hellwig
2016-05-05 15:15 ` Dan Williams
2016-05-05 15:15 ` Dan Williams
2016-05-05 15:15 ` Dan Williams
2016-05-05 15:15 ` Dan Williams
2016-05-05 15:22 ` Christoph Hellwig
2016-05-05 15:22 ` Christoph Hellwig
2016-05-05 15:22 ` Christoph Hellwig
2016-05-05 15:22 ` Christoph Hellwig
2016-05-05 16:24 ` Dan Williams
2016-05-05 16:24 ` Dan Williams
2016-05-05 16:24 ` Dan Williams
2016-05-05 16:24 ` Dan Williams
2016-05-05 21:45 ` Verma, Vishal L
2016-05-05 21:45 ` Verma, Vishal L
2016-05-05 21:45 ` Verma, Vishal L
2016-05-05 21:45 ` Verma, Vishal L
2016-05-08 9:01 ` hch
2016-05-08 9:01 ` hch
2016-05-08 9:01 ` hch
2016-05-08 9:01 ` hch
2016-05-08 18:42 ` Verma, Vishal L [this message]
2016-05-08 18:42 ` Verma, Vishal L
2016-05-08 18:42 ` Verma, Vishal L
2016-05-08 18:42 ` Verma, Vishal L
2016-05-05 21:42 ` Verma, Vishal L
2016-05-05 21:42 ` Verma, Vishal L
2016-05-05 21:42 ` Verma, Vishal L
2016-05-05 21:42 ` Verma, Vishal L
2016-05-05 21:39 ` Verma, Vishal L
2016-05-05 21:39 ` Verma, Vishal L
2016-05-05 21:39 ` Verma, Vishal L
2016-05-05 21:39 ` Verma, Vishal L
2016-05-08 9:01 ` hch
2016-05-08 9:01 ` hch
2016-05-08 9:01 ` hch
2016-05-08 9:01 ` hch
2016-04-28 21:16 ` [PATCH v4 6/7] dax: for truncate/hole-punch, do zeroing through the driver if possible Vishal Verma
2016-04-28 21:16 ` Vishal Verma
2016-04-28 21:16 ` Vishal Verma
2016-04-28 21:16 ` Vishal Verma
2016-04-28 21:16 ` [PATCH v4 7/7] dax: fix a comment in dax_zero_page_range and dax_truncate_page Vishal Verma
2016-04-28 21:16 ` Vishal Verma
2016-04-28 21:16 ` Vishal Verma
2016-04-28 21:16 ` Vishal Verma
2016-04-28 21:16 ` Vishal Verma
2016-04-29 21:55 ` [PATCH v4 8/7] Documentation: add error handling information to dax.txt Vishal Verma
2016-04-29 21:55 ` Vishal Verma
2016-04-29 21:55 ` Vishal Verma
2016-04-29 21:55 ` Vishal Verma
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=1462732956.3006.4.camel@intel.com \
--to=vishal.l.verma@intel.com \
--cc=akpm@linux-foundation.org \
--cc=axboe@fb.com \
--cc=dan.j.williams@intel.com \
--cc=david@fromorbit.com \
--cc=hch@infradead.org \
--cc=jack@suse.cz \
--cc=linux-block@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-nvdimm@ml01.01.org \
--cc=matthew@wil.cx \
--cc=viro@zeniv.linux.org.uk \
--cc=xfs@oss.sgi.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.