From: "Verma, Vishal L" <vishal.l.verma@intel.com>
To: "Williams, Dan J" <dan.j.williams@intel.com>,
"darrick.wong@oracle.com" <darrick.wong@oracle.com>
Cc: "Vyacheslav.Dubeyko@wdc.com" <Vyacheslav.Dubeyko@wdc.com>,
"jack@suse.cz" <jack@suse.cz>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
"lsf-pc@lists.linux-foundation.org"
<lsf-pc@lists.linux-foundation.org>,
"linux-nvdimm@ml01.01.org" <linux-nvdimm@ml01.01.org>,
"slava@dubeyko.com" <slava@dubeyko.com>
Subject: Re: [Lsf-pc] [LSF/MM TOPIC] Badblocks checking/representation in filesystems
Date: Wed, 18 Jan 2017 21:56:58 +0000 [thread overview]
Message-ID: <1484776549.4358.33.camel@intel.com> (raw)
In-Reply-To: <CAPcyv4hd7bpCa7d9msX0Y8gLz7WsqXT3VExQwwLuAcsmMxVTPg@mail.gmail.com>
T24gV2VkLCAyMDE3LTAxLTE4IGF0IDEzOjMyIC0wODAwLCBEYW4gV2lsbGlhbXMgd3JvdGU6DQo+
IE9uIFdlZCwgSmFuIDE4LCAyMDE3IGF0IDE6MDIgUE0sIERhcnJpY2sgSi4gV29uZw0KPiA8ZGFy
cmljay53b25nQG9yYWNsZS5jb20+IHdyb3RlOg0KPiA+IE9uIFdlZCwgSmFuIDE4LCAyMDE3IGF0
IDAzOjM5OjE3UE0gLTA1MDAsIEplZmYgTW95ZXIgd3JvdGU6DQo+ID4gPiBKYW4gS2FyYSA8amFj
a0BzdXNlLmN6PiB3cml0ZXM6DQo+ID4gPiANCj4gPiA+ID4gT24gVHVlIDE3LTAxLTE3IDE1OjE0
OjIxLCBWaXNoYWwgVmVybWEgd3JvdGU6DQo+ID4gPiA+ID4gWW91ciBub3RlIG9uIHRoZSBvbmxp
bmUgcmVwYWlyIGRvZXMgcmFpc2UgYW5vdGhlciB0YW5nZW50aWFsbHkNCj4gPiA+ID4gPiByZWxh
dGVkDQo+ID4gPiA+ID4gdG9waWMuIEN1cnJlbnRseSwgaWYgdGhlcmUgYXJlIGJhZGJsb2Nrcywg
d3JpdGVzIHZpYSB0aGUgYmlvDQo+ID4gPiA+ID4gc3VibWlzc2lvbg0KPiA+ID4gPiA+IHBhdGgg
d2lsbCBjbGVhciB0aGUgZXJyb3IgKGlmIHRoZSBoYXJkd2FyZSBpcyBhYmxlIHRvIHJlbWFwDQo+
ID4gPiA+ID4gdGhlIGJhZA0KPiA+ID4gPiA+IGxvY2F0aW9ucykuIEhvd2V2ZXIsIGlmIHRoZSBm
aWxlc3lzdGVtIGlzIG1vdW50ZWQgZWl0aCBEQVgsDQo+ID4gPiA+ID4gZXZlbg0KPiA+ID4gPiA+
IG5vbi1tbWFwIG9wZXJhdGlvbnMgLSByZWFkKCkgYW5kIHdyaXRlKCkgd2lsbCBnbyB0aHJvdWdo
IHRoZQ0KPiA+ID4gPiA+IGRheCBwYXRocw0KPiA+ID4gPiA+IChkYXhfZG9faW8oKSkuIFdlIGhh
dmVuJ3QgZm91bmQgYSBnb29kL2FncmVlYWJsZSB3YXkgdG8NCj4gPiA+ID4gPiBwZXJmb3JtDQo+
ID4gPiA+ID4gZXJyb3ItY2xlYXJpbmcgaW4gdGhpcyBjYXNlLiBTbyBjdXJyZW50bHksIGlmIGEg
ZGF4IG1vdW50ZWQNCj4gPiA+ID4gPiBmaWxlc3lzdGVtDQo+ID4gPiA+ID4gaGFzIGJhZGJsb2Nr
cywgdGhlIG9ubHkgd2F5IHRvIGNsZWFyIHRob3NlIGJhZGJsb2NrcyBpcyB0bw0KPiA+ID4gPiA+
IG1vdW50IGl0DQo+ID4gPiA+ID4gd2l0aG91dCBEQVgsIGFuZCBvdmVyd3JpdGUvemVybyB0aGUg
YmFkIGxvY2F0aW9ucy4gVGhpcyBpcyBhDQo+ID4gPiA+ID4gcHJldHR5DQo+ID4gPiA+ID4gdGVy
cmlibGUgdXNlciBleHBlcmllbmNlLCBhbmQgSSdtIGhvcGluZyB0aGlzIGNhbiBiZSBzb2x2ZWQg
aW4NCj4gPiA+ID4gPiBhIGJldHRlcg0KPiA+ID4gPiA+IHdheS4NCj4gPiA+ID4gDQo+ID4gPiA+
IFBsZWFzZSByZW1pbmQgbWUsIHdoYXQgaXMgdGhlIHByb2JsZW0gd2l0aCBEQVggY29kZSBkb2lu
Zw0KPiA+ID4gPiBuZWNlc3Nhcnkgd29yayB0bw0KPiA+ID4gPiBjbGVhciB0aGUgZXJyb3Igd2hl
biBpdCBnZXRzIEVJTyBmcm9tIG1lbWNweSBvbiB3cml0ZT8NCj4gPiA+IA0KPiA+ID4gWW91IHdv
bid0IGdldCBhbiBNQ0UgZm9yIGEgc3RvcmU7wqDCoG9ubHkgbG9hZHMgZ2VuZXJhdGUgdGhlbS4N
Cj4gPiA+IA0KPiA+ID4gV29uJ3QgZmFsbG9jYXRlIEZMX1pFUk9fUkFOR0UgY2xlYXIgYmFkIGJs
b2NrcyB3aGVuIG1vdW50ZWQgd2l0aA0KPiA+ID4gLW8gZGF4Pw0KPiA+IA0KPiA+IE5vdCBuZWNl
c3NhcmlseTsgWEZTIHVzdWFsbHkgaW1wbGVtZW50cyB0aGlzIGJ5IHB1bmNoaW5nIG91dCB0aGUN
Cj4gPiByYW5nZQ0KPiA+IGFuZCB0aGVuIHJlYWxsb2NhdGluZyBpdCBhcyB1bndyaXR0ZW4gYmxv
Y2tzLg0KPiA+IA0KPiANCj4gVGhhdCBkb2VzIGNsZWFyIHRoZSBlcnJvciBiZWNhdXNlIHRoZSB1
bndyaXR0ZW4gYmxvY2tzIGFyZSB6ZXJvZWQgYW5kDQo+IGVycm9ycyBjbGVhcmVkIHdoZW4gdGhl
eSBiZWNvbWUgYWxsb2NhdGVkIGFnYWluLg0KDQpZZXMsIHRoZSBwcm9ibGVtIHdhcyB0aGF0IHdy
aXRlcyB3b24ndCBjbGVhciBlcnJvcnMuIHplcm9pbmcgdGhyb3VnaA0KZWl0aGVyIGhvbGUtcHVu
Y2gsIHRydW5jYXRlLCB1bmxpbmtpbmcgdGhlIGZpbGUgc2hvdWxkIGFsbCB3b3JrDQooYXNzdW1p
bmcgdGhlIGhvbGUtcHVuY2ggb3IgdHJ1bmNhdGUgcmFuZ2VzIHdob2xseSBjb250YWluIHRoZQ0K
J2JhZGJsb2NrJyBzZWN0b3IpLg0KDQoNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18NCj4gTGludXgtbnZkaW1tIG1haWxpbmcgbGlzdA0KPiBMaW51eC1u
dmRpbW1AbGlzdHMuMDEub3JnDQo+IGh0dHBzOi8vbGlzdHMuMDEub3JnL21haWxtYW4vbGlzdGlu
Zm8vbGludXgtbnZkaW1t
WARNING: multiple messages have this Message-ID (diff)
From: "Verma, Vishal L" <vishal.l.verma-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
To: "Williams,
Dan J" <dan.j.williams-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
"darrick.wong-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org"
<darrick.wong-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
Cc: "jack-AlSwsSmVLrQ@public.gmane.org"
<jack-AlSwsSmVLrQ@public.gmane.org>,
"Vyacheslav.Dubeyko-Sjgp3cTcYWE@public.gmane.org"
<Vyacheslav.Dubeyko-Sjgp3cTcYWE@public.gmane.org>,
"linux-nvdimm-y27Ovi1pjclAfugRpC6u6w@public.gmane.org"
<linux-nvdimm-y27Ovi1pjclAfugRpC6u6w@public.gmane.org>,
"linux-block-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-block-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"slava-yeENwD64cLxBDgjK7y7TUQ@public.gmane.org"
<slava-yeENwD64cLxBDgjK7y7TUQ@public.gmane.org>,
"linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"lsf-pc-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org"
<lsf-pc-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>
Subject: Re: [Lsf-pc] [LSF/MM TOPIC] Badblocks checking/representation in filesystems
Date: Wed, 18 Jan 2017 21:56:58 +0000 [thread overview]
Message-ID: <1484776549.4358.33.camel@intel.com> (raw)
In-Reply-To: <CAPcyv4hd7bpCa7d9msX0Y8gLz7WsqXT3VExQwwLuAcsmMxVTPg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Wed, 2017-01-18 at 13:32 -0800, Dan Williams wrote:
> On Wed, Jan 18, 2017 at 1:02 PM, Darrick J. Wong
> <darrick.wong@oracle.com> wrote:
> > On Wed, Jan 18, 2017 at 03:39:17PM -0500, Jeff Moyer wrote:
> > > Jan Kara <jack@suse.cz> writes:
> > >
> > > > On Tue 17-01-17 15:14:21, Vishal Verma wrote:
> > > > > Your note on the online repair does raise another tangentially
> > > > > related
> > > > > topic. Currently, if there are badblocks, writes via the bio
> > > > > submission
> > > > > path will clear the error (if the hardware is able to remap
> > > > > the bad
> > > > > locations). However, if the filesystem is mounted eith DAX,
> > > > > even
> > > > > non-mmap operations - read() and write() will go through the
> > > > > dax paths
> > > > > (dax_do_io()). We haven't found a good/agreeable way to
> > > > > perform
> > > > > error-clearing in this case. So currently, if a dax mounted
> > > > > filesystem
> > > > > has badblocks, the only way to clear those badblocks is to
> > > > > mount it
> > > > > without DAX, and overwrite/zero the bad locations. This is a
> > > > > pretty
> > > > > terrible user experience, and I'm hoping this can be solved in
> > > > > a better
> > > > > way.
> > > >
> > > > Please remind me, what is the problem with DAX code doing
> > > > necessary work to
> > > > clear the error when it gets EIO from memcpy on write?
> > >
> > > You won't get an MCE for a store; only loads generate them.
> > >
> > > Won't fallocate FL_ZERO_RANGE clear bad blocks when mounted with
> > > -o dax?
> >
> > Not necessarily; XFS usually implements this by punching out the
> > range
> > and then reallocating it as unwritten blocks.
> >
>
> That does clear the error because the unwritten blocks are zeroed and
> errors cleared when they become allocated again.
Yes, the problem was that writes won't clear errors. zeroing through
either hole-punch, truncate, unlinking the file should all work
(assuming the hole-punch or truncate ranges wholly contain the
'badblock' sector).
> _______________________________________________
> Linux-nvdimm mailing list
> Linux-nvdimm@lists.01.org
> https://lists.01.org/mailman/listinfo/linux-nvdimm
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
WARNING: multiple messages have this Message-ID (diff)
From: "Verma, Vishal L" <vishal.l.verma@intel.com>
To: "Williams, Dan J" <dan.j.williams@intel.com>,
"darrick.wong@oracle.com" <darrick.wong@oracle.com>
Cc: "Vyacheslav.Dubeyko@wdc.com" <Vyacheslav.Dubeyko@wdc.com>,
"jack@suse.cz" <jack@suse.cz>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
"lsf-pc@lists.linux-foundation.org"
<lsf-pc@lists.linux-foundation.org>,
"linux-nvdimm@ml01.01.org" <linux-nvdimm@ml01.01.org>,
"slava@dubeyko.com" <slava@dubeyko.com>
Subject: Re: [Lsf-pc] [LSF/MM TOPIC] Badblocks checking/representation in filesystems
Date: Wed, 18 Jan 2017 21:56:58 +0000 [thread overview]
Message-ID: <1484776549.4358.33.camel@intel.com> (raw)
In-Reply-To: <CAPcyv4hd7bpCa7d9msX0Y8gLz7WsqXT3VExQwwLuAcsmMxVTPg@mail.gmail.com>
On Wed, 2017-01-18 at 13:32 -0800, Dan Williams wrote:
> On Wed, Jan 18, 2017 at 1:02 PM, Darrick J. Wong
> <darrick.wong@oracle.com> wrote:
> > On Wed, Jan 18, 2017 at 03:39:17PM -0500, Jeff Moyer wrote:
> > > Jan Kara <jack@suse.cz> writes:
> > >
> > > > On Tue 17-01-17 15:14:21, Vishal Verma wrote:
> > > > > Your note on the online repair does raise another tangentially
> > > > > related
> > > > > topic. Currently, if there are badblocks, writes via the bio
> > > > > submission
> > > > > path will clear the error (if the hardware is able to remap
> > > > > the bad
> > > > > locations). However, if the filesystem is mounted eith DAX,
> > > > > even
> > > > > non-mmap operations - read() and write() will go through the
> > > > > dax paths
> > > > > (dax_do_io()). We haven't found a good/agreeable way to
> > > > > perform
> > > > > error-clearing in this case. So currently, if a dax mounted
> > > > > filesystem
> > > > > has badblocks, the only way to clear those badblocks is to
> > > > > mount it
> > > > > without DAX, and overwrite/zero the bad locations. This is a
> > > > > pretty
> > > > > terrible user experience, and I'm hoping this can be solved in
> > > > > a better
> > > > > way.
> > > >
> > > > Please remind me, what is the problem with DAX code doing
> > > > necessary work to
> > > > clear the error when it gets EIO from memcpy on write?
> > >
> > > You won't get an MCE for a store; only loads generate them.
> > >
> > > Won't fallocate FL_ZERO_RANGE clear bad blocks when mounted with
> > > -o dax?
> >
> > Not necessarily; XFS usually implements this by punching out the
> > range
> > and then reallocating it as unwritten blocks.
> >
>
> That does clear the error because the unwritten blocks are zeroed and
> errors cleared when they become allocated again.
Yes, the problem was that writes won't clear errors. zeroing through
either hole-punch, truncate, unlinking the file should all work
(assuming the hole-punch or truncate ranges wholly contain the
'badblock' sector).
> _______________________________________________
> Linux-nvdimm mailing list
> Linux-nvdimm@lists.01.org
> https://lists.01.org/mailman/listinfo/linux-nvdimm
next prev parent reply other threads:[~2017-01-18 21:56 UTC|newest]
Thread overview: 86+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <at1mp6pou4lenesjdgh22k4p.1484345585589@email.android.com>
[not found] ` <b9rbflutjt10mb4ofherta8j.1484345610771@email.android.com>
2017-01-14 0:00 ` [LSF/MM TOPIC] Badblocks checking/representation in filesystems Slava Dubeyko
2017-01-14 0:00 ` Slava Dubeyko
2017-01-14 0:00 ` Slava Dubeyko
2017-01-14 0:49 ` Vishal Verma
2017-01-14 0:49 ` Vishal Verma
2017-01-16 2:27 ` Slava Dubeyko
2017-01-16 2:27 ` Slava Dubeyko
2017-01-16 2:27 ` Slava Dubeyko
2017-01-17 14:37 ` [Lsf-pc] " Jan Kara
2017-01-17 14:37 ` Jan Kara
2017-01-17 15:08 ` Christoph Hellwig
2017-01-17 15:08 ` Christoph Hellwig
2017-01-17 22:14 ` Vishal Verma
2017-01-17 22:14 ` Vishal Verma
2017-01-18 10:16 ` Jan Kara
2017-01-18 10:16 ` Jan Kara
2017-01-18 20:39 ` Jeff Moyer
2017-01-18 20:39 ` Jeff Moyer
2017-01-18 21:02 ` Darrick J. Wong
2017-01-18 21:02 ` Darrick J. Wong
2017-01-18 21:32 ` Dan Williams
2017-01-18 21:32 ` Dan Williams
2017-01-18 21:56 ` Verma, Vishal L [this message]
2017-01-18 21:56 ` Verma, Vishal L
2017-01-18 21:56 ` Verma, Vishal L
2017-01-19 8:10 ` Jan Kara
2017-01-19 8:10 ` Jan Kara
2017-01-19 18:59 ` Vishal Verma
2017-01-19 18:59 ` Vishal Verma
2017-01-19 19:03 ` Dan Williams
2017-01-19 19:03 ` Dan Williams
2017-01-20 9:03 ` Jan Kara
2017-01-20 9:03 ` Jan Kara
2017-01-17 23:15 ` Slava Dubeyko
2017-01-17 23:15 ` Slava Dubeyko
2017-01-17 23:15 ` Slava Dubeyko
2017-01-18 20:47 ` Jeff Moyer
2017-01-18 20:47 ` Jeff Moyer
2017-01-19 2:56 ` Slava Dubeyko
2017-01-19 2:56 ` Slava Dubeyko
2017-01-19 2:56 ` Slava Dubeyko
2017-01-19 19:33 ` Jeff Moyer
2017-01-19 19:33 ` Jeff Moyer
2017-01-17 6:33 ` Darrick J. Wong
2017-01-17 6:33 ` Darrick J. Wong
2017-01-17 21:35 ` Vishal Verma
2017-01-17 21:35 ` Vishal Verma
2017-01-17 22:15 ` Andiry Xu
2017-01-17 22:15 ` Andiry Xu
2017-01-17 22:37 ` Vishal Verma
2017-01-17 22:37 ` Vishal Verma
2017-01-17 23:20 ` Andiry Xu
2017-01-17 23:20 ` Andiry Xu
2017-01-17 23:51 ` Vishal Verma
2017-01-17 23:51 ` Vishal Verma
2017-01-18 1:58 ` Andiry Xu
2017-01-18 1:58 ` Andiry Xu
2017-01-20 0:32 ` Verma, Vishal L
2017-01-20 0:32 ` Verma, Vishal L
2017-01-20 0:32 ` Verma, Vishal L
2017-01-18 9:38 ` [Lsf-pc] " Jan Kara
2017-01-18 9:38 ` Jan Kara
2017-01-19 21:17 ` Vishal Verma
2017-01-19 21:17 ` Vishal Verma
2017-01-20 9:47 ` Jan Kara
2017-01-20 9:47 ` Jan Kara
2017-01-20 15:42 ` Dan Williams
2017-01-20 15:42 ` Dan Williams
2017-01-24 7:46 ` Jan Kara
2017-01-24 7:46 ` Jan Kara
2017-01-24 19:59 ` Vishal Verma
2017-01-24 19:59 ` Vishal Verma
2017-01-18 0:16 ` Andreas Dilger
2017-01-18 2:01 ` Andiry Xu
2017-01-18 2:01 ` Andiry Xu
2017-01-18 3:08 ` Lu Zhang
2017-01-18 3:08 ` Lu Zhang
2017-01-20 0:46 ` Vishal Verma
2017-01-20 0:46 ` Vishal Verma
2017-01-20 9:24 ` Yasunori Goto
2017-01-20 9:24 ` Yasunori Goto
2017-01-21 0:23 ` Kani, Toshimitsu
2017-01-21 0:23 ` Kani, Toshimitsu
2017-01-21 0:23 ` Kani, Toshimitsu
2017-01-20 0:55 ` Verma, Vishal L
2017-01-20 0:55 ` Verma, Vishal L
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=1484776549.4358.33.camel@intel.com \
--to=vishal.l.verma@intel.com \
--cc=Vyacheslav.Dubeyko@wdc.com \
--cc=dan.j.williams@intel.com \
--cc=darrick.wong@oracle.com \
--cc=jack@suse.cz \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-nvdimm@ml01.01.org \
--cc=lsf-pc@lists.linux-foundation.org \
--cc=slava@dubeyko.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.