From: "Verma, Vishal L" <vishal.l.verma@intel.com>
To: "hch@infradead.org" <hch@infradead.org>,
"boaz@plexistor.com" <boaz@plexistor.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
"linux-nvdimm@ml01.01.org" <linux-nvdimm@ml01.01.org>,
"xfs@oss.sgi.com" <xfs@oss.sgi.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"viro@zeniv.linux.org.uk" <viro@zeniv.linux.org.uk>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"axboe@fb.com" <axboe@fb.com>,
"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: Thu, 5 May 2016 21:39:14 +0000 [thread overview]
Message-ID: <1462484343.29294.1.camel@intel.com> (raw)
In-Reply-To: <20160505142433.GA4557@infradead.org>
T24gVGh1LCAyMDE2LTA1LTA1IGF0IDA3OjI0IC0wNzAwLCBDaHJpc3RvcGggSGVsbHdpZyB3cm90
ZToNCj4gT24gTW9uLCBNYXkgMDIsIDIwMTYgYXQgMDY6NDE6NTFQTSArMDMwMCwgQm9heiBIYXJy
b3NoIHdyb3RlOg0KPiA+IA0KPiA+ID4gDQo+ID4gPiBBbGwgSU8gaW4gYSBkYXggZmlsZXN5c3Rl
bSB1c2VkIHRvIGdvIHRocm91Z2ggZGF4X2RvX2lvLCB3aGljaA0KPiA+ID4gY2Fubm90DQo+ID4g
PiBoYW5kbGUgbWVkaWEgZXJyb3JzLCBhbmQgdGh1cyBjYW5ub3QgcHJvdmlkZSBhIHJlY292ZXJ5
IHBhdGggdGhhdA0KPiA+ID4gY2FuDQo+ID4gPiBzZW5kIGEgd3JpdGUgdGhyb3VnaCB0aGUgZHJp
dmVyIHRvIGNsZWFyIGVycm9ycy4NCj4gPiA+IA0KPiA+ID4gQWRkIGEgbmV3IGlvY2IgZmxhZyBm
b3IgREFYLCBhbmQgc2V0IGl0IG9ubHkgZm9yIERBWCBtb3VudHMuIEluDQo+ID4gPiB0aGUgSU8N
Cj4gPiA+IHBhdGggZm9yIERBWCBmaWxlc3lzdGVtcywgdXNlIHRoZSBzYW1lIGRpcmVjdF9JTyBw
YXRoIGZvciBib3RoIERBWA0KPiA+ID4gYW5kDQo+ID4gPiBkaXJlY3RfaW8gaW9jYnMsIGJ1dCB1
c2UgdGhlIGZsYWdzIHRvIGlkZW50aWZ5IHdoZW4gd2UgYXJlIGluDQo+ID4gPiBPX0RJUkVDVA0K
PiA+ID4gbW9kZSB2cyBub24gT19ESVJFQ1Qgd2l0aCBEQVgsIGFuZCBmb3IgT19ESVJFQ1QsIHVz
ZSB0aGUNCj4gPiA+IGNvbnZlbnRpb25hbA0KPiA+ID4gZGlyZWN0X0lPIHBhdGggaW5zdGVhZCBv
ZiBEQVguDQo+ID4gPiANCj4gPiBSZWFsbHk/IFdoYXQgYXJlIHlvdXIgdGhpbmtpbmcgaGVyZT8N
Cj4gPiANCj4gPiBXaGF0IGFib3V0IGFsbCB0aGUgY3VycmVudCB1c2VycyBvZiBPX0RJUkVDVCwg
eW91IGhhdmUganVzdCBtYWRlDQo+ID4gdGhlbQ0KPiA+IDQgdGltZXMgc2xvd2VyIGFuZCAibGVz
cyBjb25jdXJyZW50KiIgdGhlbiAiYnVmZnJlZCBpbyIgdXNlcnMuIFNpbmNlDQo+ID4gZGlyZWN0
X0lPIHBhdGggd2lsbCBxdWV1ZSBhbiBJTyByZXF1ZXN0IGFuZCBhbGwuDQo+ID4gKEFuZCBpZiBp
dCBpcyBub3Qgc28gc2xvdyB0aGVuIHdoeSBkbyB3ZSBuZWVkIGRheF9kb19pbyBhdCBhbGw/DQo+
ID4gW1JoZXRvcmljYWxdKQ0KPiA+IA0KPiA+IEkgaGF0ZSBpdCB0aGF0IHlvdSBvdmVybG9hZCB0
aGUgc2VtYW50aWNzIG9mIGEga25vd24gYW5kIGV4cGVjdGVkDQo+ID4gT19ESVJFQ1QgZmxhZywg
Zm9yIHNwZWNpYWwgcG1lbSBxdWlya3MuIFRoaXMgaXMgYW4gaW5jb21wYXRpYmxlDQo+ID4gYW5k
IHVucmVsYXRlZCBvdmVybG9hZCBvZiB0aGUgc2VtYW50aWNzIG9mIE9fRElSRUNULg0KPiBBZ3Jl
ZWQgLSBtYWtpZyBPX0RJUkVDVCBsZXNzIGRpcmVjdCB0aGFuIG5vdCBoYXZpbmcgaXQgaXMgcGxh
aW4NCj4gc3R1cGlkLA0KPiBhbmQgSSBzb21laG93IG1pc3NlZCB0aGlzIGluaXRpYWxseS4NCg0K
SG93IGlzIGl0IGFueSAnbGVzcyBkaXJlY3QnPyBBbGwgaXQgZG9lcyBub3cgaXMgZm9sbG93IHRo
ZSBibG9ja2Rldg0KT19ESVJFQ1QgcGF0aC4gVGhlcmUgc3RpbGwgaXNuJ3QgYW55IHBhZ2UgY2Fj
aGUgaW52b2x2ZWQuLg0KDQo+IA0KPiBUaGlzIHdob2xlIERBWCBzdG9yeSB0dXJucyBpbnRvIGEg
bWFqb3IgbmlnaHRtYXJlLCBhbmQgSSBmZWFyIGFsbCBvdXINCj4gaG9kZ2UgcG9kZ2UgdHdlYWtz
IHRvIHRoZSBzZW1hbnRpY3MgYXJlbid0IGhlbHBpbmcgaXQuDQo+IA0KPiBJdCBzZWVtcyBsaWtl
IHdlIHNpbXBseSBuZWVkIGFuIGV4cGxpY2l0IE9fREFYIGZvciB0aGUgcmVhZC93cml0ZQ0KPiBi
eXBhc3MgaWYgY2FuJ3Qgc29ydCBvdXQgdGhlIHNlbWFudGljcyAoZXJyb3IsIHdyaXRlciBzeW5j
aHJvbml6YXRpb24pDQo+IGp1c3QgYXMgd2UgbmVlZCBhIHNwZWNpYWwgZmxhZyBmb3IgTU1BUC4u
WARNING: multiple messages have this Message-ID (diff)
From: "Verma, Vishal L" <vishal.l.verma@intel.com>
To: "hch@infradead.org" <hch@infradead.org>,
"boaz@plexistor.com" <boaz@plexistor.com>
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>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH v4 5/7] fs: prioritize and separate direct_io from dax_io
Date: Thu, 5 May 2016 21:39:14 +0000 [thread overview]
Message-ID: <1462484343.29294.1.camel@intel.com> (raw)
In-Reply-To: <20160505142433.GA4557@infradead.org>
On Thu, 2016-05-05 at 07:24 -0700, Christoph Hellwig wrote:
> On Mon, May 02, 2016 at 06:41:51PM +0300, Boaz Harrosh wrote:
> >
> > >
> > > All IO in a dax filesystem used to go through dax_do_io, which
> > > cannot
> > > handle media errors, and thus cannot provide a recovery path that
> > > can
> > > send a write through the driver to clear errors.
> > >
> > > Add a new iocb flag for DAX, and set it only for DAX mounts. In
> > > the IO
> > > path for DAX filesystems, use the same direct_IO path for both DAX
> > > and
> > > direct_io iocbs, but use the flags to identify when we are in
> > > O_DIRECT
> > > mode vs non O_DIRECT with DAX, and for O_DIRECT, use the
> > > conventional
> > > direct_IO path instead of DAX.
> > >
> > Really? What are your thinking here?
> >
> > What about all the current users of O_DIRECT, you have just made
> > them
> > 4 times slower and "less concurrent*" then "buffred io" users. Since
> > direct_IO path will queue an IO request and all.
> > (And if it is not so slow then why do we need dax_do_io at all?
> > [Rhetorical])
> >
> > I hate it that you overload the semantics of a known and expected
> > O_DIRECT flag, for special pmem quirks. This is an incompatible
> > and unrelated overload of the semantics of O_DIRECT.
> Agreed - makig O_DIRECT less direct than not having it is plain
> stupid,
> and I somehow missed this initially.
How is it any 'less direct'? All it does now is follow the blockdev
O_DIRECT path. There still isn't any page cache involved..
>
> This whole DAX story turns into a major nightmare, and I fear all our
> hodge podge tweaks to the semantics aren't helping it.
>
> It seems like we simply need an explicit O_DAX for the read/write
> bypass if can't sort out the semantics (error, writer synchronization)
> just as we need a special flag for MMAP..
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
WARNING: multiple messages have this Message-ID (diff)
From: "Verma, Vishal L" <vishal.l.verma@intel.com>
To: "hch@infradead.org" <hch@infradead.org>,
"boaz@plexistor.com" <boaz@plexistor.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
"linux-nvdimm@ml01.01.org" <linux-nvdimm@ml01.01.org>,
"xfs@oss.sgi.com" <xfs@oss.sgi.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"viro@zeniv.linux.org.uk" <viro@zeniv.linux.org.uk>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"axboe@fb.com" <axboe@fb.com>,
"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: Thu, 5 May 2016 21:39:14 +0000 [thread overview]
Message-ID: <1462484343.29294.1.camel@intel.com> (raw)
In-Reply-To: <20160505142433.GA4557@infradead.org>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 1980 bytes --]
On Thu, 2016-05-05 at 07:24 -0700, Christoph Hellwig wrote:
> On Mon, May 02, 2016 at 06:41:51PM +0300, Boaz Harrosh wrote:
> >
> > >
> > > All IO in a dax filesystem used to go through dax_do_io, which
> > > cannot
> > > handle media errors, and thus cannot provide a recovery path that
> > > can
> > > send a write through the driver to clear errors.
> > >
> > > Add a new iocb flag for DAX, and set it only for DAX mounts. In
> > > the IO
> > > path for DAX filesystems, use the same direct_IO path for both DAX
> > > and
> > > direct_io iocbs, but use the flags to identify when we are in
> > > O_DIRECT
> > > mode vs non O_DIRECT with DAX, and for O_DIRECT, use the
> > > conventional
> > > direct_IO path instead of DAX.
> > >
> > Really? What are your thinking here?
> >
> > What about all the current users of O_DIRECT, you have just made
> > them
> > 4 times slower and "less concurrent*" then "buffred io" users. Since
> > direct_IO path will queue an IO request and all.
> > (And if it is not so slow then why do we need dax_do_io at all?
> > [Rhetorical])
> >
> > I hate it that you overload the semantics of a known and expected
> > O_DIRECT flag, for special pmem quirks. This is an incompatible
> > and unrelated overload of the semantics of O_DIRECT.
> Agreed - makig O_DIRECT less direct than not having it is plain
> stupid,
> and I somehow missed this initially.
How is it any 'less direct'? All it does now is follow the blockdev
O_DIRECT path. There still isn't any page cache involved..
>
> This whole DAX story turns into a major nightmare, and I fear all our
> hodge podge tweaks to the semantics aren't helping it.
>
> It seems like we simply need an explicit O_DAX for the read/write
> bypass if can't sort out the semantics (error, writer synchronization)
> just as we need a special flag for MMAP..N‹§²æìr¸›zǧu©ž²Æ {\b†éì¹»\x1c®&Þ–)îÆi¢žØ^n‡r¶‰šŽŠÝ¢j$½§$¢¸\x05¢¹¨è§~Š'.)îÄÃ,yèm¶ŸÿÃ\f%Š{±šj+ƒðèž×¦j)Z†·Ÿ
WARNING: multiple messages have this Message-ID (diff)
From: "Verma, Vishal L" <vishal.l.verma@intel.com>
To: "hch@infradead.org" <hch@infradead.org>,
"boaz@plexistor.com" <boaz@plexistor.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
"linux-nvdimm@ml01.01.org" <linux-nvdimm@ml01.01.org>,
"xfs@oss.sgi.com" <xfs@oss.sgi.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"viro@zeniv.linux.org.uk" <viro@zeniv.linux.org.uk>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"axboe@fb.com" <axboe@fb.com>,
"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: Thu, 5 May 2016 21:39:14 +0000 [thread overview]
Message-ID: <1462484343.29294.1.camel@intel.com> (raw)
In-Reply-To: <20160505142433.GA4557@infradead.org>
On Thu, 2016-05-05 at 07:24 -0700, Christoph Hellwig wrote:
> On Mon, May 02, 2016 at 06:41:51PM +0300, Boaz Harrosh wrote:
> >
> > >
> > > All IO in a dax filesystem used to go through dax_do_io, which
> > > cannot
> > > handle media errors, and thus cannot provide a recovery path that
> > > can
> > > send a write through the driver to clear errors.
> > >
> > > Add a new iocb flag for DAX, and set it only for DAX mounts. In
> > > the IO
> > > path for DAX filesystems, use the same direct_IO path for both DAX
> > > and
> > > direct_io iocbs, but use the flags to identify when we are in
> > > O_DIRECT
> > > mode vs non O_DIRECT with DAX, and for O_DIRECT, use the
> > > conventional
> > > direct_IO path instead of DAX.
> > >
> > Really? What are your thinking here?
> >
> > What about all the current users of O_DIRECT, you have just made
> > them
> > 4 times slower and "less concurrent*" then "buffred io" users. Since
> > direct_IO path will queue an IO request and all.
> > (And if it is not so slow then why do we need dax_do_io at all?
> > [Rhetorical])
> >
> > I hate it that you overload the semantics of a known and expected
> > O_DIRECT flag, for special pmem quirks. This is an incompatible
> > and unrelated overload of the semantics of O_DIRECT.
> Agreed - makig O_DIRECT less direct than not having it is plain
> stupid,
> and I somehow missed this initially.
How is it any 'less direct'? All it does now is follow the blockdev
O_DIRECT path. There still isn't any page cache involved..
>
> This whole DAX story turns into a major nightmare, and I fear all our
> hodge podge tweaks to the semantics aren't helping it.
>
> It seems like we simply need an explicit O_DAX for the read/write
> bypass if can't sort out the semantics (error, writer synchronization)
> just as we need a special flag for MMAP..
next prev parent reply other threads:[~2016-05-05 21:39 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
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 [this message]
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=1462484343.29294.1.camel@intel.com \
--to=vishal.l.verma@intel.com \
--cc=akpm@linux-foundation.org \
--cc=axboe@fb.com \
--cc=boaz@plexistor.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.