From: "Verma, Vishal L" <vishal.l.verma@intel.com>
To: "lsf-pc@lists.linux-foundation.org" <lsf-pc@lists.linux-foundation.org>
Cc: "linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
Subject: [LSF/MM TOPIC] Badblocks checking/representation in filesystems
Date: Fri, 13 Jan 2017 21:40:26 +0000 [thread overview]
Message-ID: <1484343558.4358.26.camel@intel.com> (raw)
VGhlIGN1cnJlbnQgaW1wbGVtZW50YXRpb24gb2YgYmFkYmxvY2tzLCB3aGVyZSB3ZSBjb25zdWx0
IHRoZSBiYWRibG9ja3MNCmxpc3QgZm9yIGV2ZXJ5IElPIGluIHRoZSBibG9jayBkcml2ZXIgd29y
a3MsIGFuZCBpcyBhIGxhc3Qgb3B0aW9uDQpmYWlsc2FmZSwgYnV0IGZyb20gYSB1c2VyIHBlcnNw
ZWN0aXZlLCBpdCBpc24ndCB0aGUgZWFzaWVzdCBpbnRlcmZhY2UgdG8NCndvcmsgd2l0aC4NCg0K
QSB3aGlsZSBiYWNrLCBEYXZlIENoaW5uZXIgaGFkIHN1Z2dlc3RlZCBhIG1vdmUgdG93YXJkcyBz
bWFydGVyDQpoYW5kbGluZywgYW5kIEkgcG9zdGVkIGluaXRpYWwgUkZDIHBhdGNoZXMgWzFdLCBi
dXQgc2luY2UgdGhlbiB0aGUgdG9waWMNCmhhc24ndCByZWFsbHkgbW92ZWQgZm9yd2FyZC4NCg0K
SSdkIGxpa2UgdG8gcHJvcG9zZSBhbmQgaGF2ZSBhIGRpc2N1c3Npb24gYWJvdXQgdGhlIGZvbGxv
d2luZyBuZXcNCmZ1bmN0aW9uYWxpdHk6DQoNCjEuIEZpbGVzeXN0ZW1zIGRldmVsb3AgYSBuYXRp
dmUgcmVwcmVzZW50YXRpb24gb2YgYmFkYmxvY2tzLiBGb3INCmV4YW1wbGUsIGluIHhmcywgdGhp
cyB3b3VsZCAocHJlc3VtYWJseSkgYmUgbGlua2VkIHRvIHRoZSByZXZlcnNlDQptYXBwaW5nIGJ0
cmVlLiBUaGUgZmlsZXN5c3RlbSByZXByZXNlbnRhdGlvbiBoYXMgdGhlIHBvdGVudGlhbCB0byBi
ZcKgDQptb3JlIGVmZmljaWVudCB0aGFuIHRoZSBibG9jayBkcml2ZXIgZG9pbmcgdGhlIGNoZWNr
LCBhcyB0aGUgZnMgY2FuDQpjaGVjayB0aGUgSU8gaGFwcGVuaW5nIG9uIGEgZmlsZSBhZ2FpbnN0
IGp1c3QgdGhhdCBmaWxlJ3MgcmFuZ2UuIEluDQpjb250cmFzdCwgdG9kYXksIHRoZSBibG9jayBk
cml2ZXIgY2hlY2tzIGFnYWluc3QgdGhlIHdob2xlIGJsb2NrIGRldmljZQ0KcmFuZ2UgZm9yIGV2
ZXJ5IElPLiBPbiBlbmNvdW50ZXJpbmcgYmFkYmxvY2tzLCB0aGUgZmlsZXN5c3RlbSBjYW4NCmdl
bmVyYXRlIGEgYmV0dGVyIG5vdGlmaWNhdGlvbi9lcnJvciBtZXNzYWdlIHRoYXQgcG9pbnRzIHRo
ZSB1c2VyIHRvwqANCihmaWxlLCBvZmZzZXQpIGFzIG9wcG9zZWQgdG8gdGhlIGJsb2NrIGRyaXZl
ciwgd2hpY2ggY2FuIG9ubHkgcHJvdmlkZQ0KKGJsb2NrLWRldmljZSwgc2VjdG9yKS4NCg0KMi4g
VGhlIGJsb2NrIGxheWVyIGFkZHMgYSBub3RpZmllciB0byBiYWRibG9jayBhZGRpdGlvbi9yZW1v
dmFsDQpvcGVyYXRpb25zLCB3aGljaCB0aGUgZmlsZXN5c3RlbSBzdWJzY3JpYmVzIHRvLCBhbmQg
dXNlcyB0byBtYWludGFpbiBpdHMNCmJhZGJsb2NrcyBhY2NvdW50aW5nLiAoVGhpcyBwYXJ0IGlz
IGltcGxlbWVudGVkIGFzIGEgcHJvb2Ygb2YgY29uY2VwdCBpbg0KdGhlIFJGQyBtZW50aW9uZWQg
YWJvdmUgWzFdKS4NCg0KMy4gVGhlIGZpbGVzeXN0ZW0gaGFzIGEgd2F5IG9mIHRlbGxpbmcgdGhl
IGJsb2NrIGRyaXZlciAoYSBmbGFnPyBhDQpkaWZmZXJlbnQvbmV3IGludGVyZmFjZT8pIHRoYXQg
aXQgaXMgcmVzcG9uc2libGUgZm9yIGJhZGJsb2NrIGNoZWNraW5nDQpzbyB0aGF0IHRoZSBkcml2
ZXIgZG9lc24ndCBoYXZlIHRvIGRvIGl0cyBjaGVjay4gVGhlIGRyaXZlciBjaGVja2luZw0Kd2ls
bCBoYXZlIHRvIHJlbWFpbiBpbiBwbGFjZSBhcyBhIGNhdGNoLWFsbCBmb3IgZmlsZXN5c3RlbXMv
aW50ZXJmYWNlcw0KdGhhdCBkb24ndCBvciBhcmVuJ3QgY2FwYWJsZSBvZiBkb2luZyB0aGUgY2hl
Y2tzIGF0IGEgaGlnaGVyIGxheWVyLg0KDQoNCkFkZGl0aW9uYWxseSwgSSBzYXcgc29tZSBkaXNj
dXNzaW9uIGFib3V0IGxvZ2ljYWwgZGVwb3Agb24gdGhlIGxpc3RzDQphZ2FpbiwgYW5kIEkgd2Fz
IGludm9sdmVkIHdpdGggZGlzY3Vzc2lvbnMgbGFzdCB5ZWFyIGFib3V0IGV4cGFuZGluZyB0aGUN
CnRoZSBiYWRibG9ja3MgaW5mcmFzdHJ1Y3R1cmUgZm9yIHRoaXMgdXNlLiBJZiB0aGF0IGlzIGEg
dG9waWMgYWdhaW4gdGhpcw0KeWVhciwgSSdkIGxpa2UgdG8gYmUgaW52b2x2ZWQgaW4gaXQgdG9v
Lg0KDQpJJ20gYWxzbyBpbnRlcmVzdGVkIGluIHBhcnRpY2lwYXRpbmcgaW4gYW55IG90aGVyIHBt
ZW0vTlZESU1NIHJlbGF0ZWQNCmRpc2N1c3Npb25zLg0KDQoNClRoYW5rIHlvdSwNCgktVmlzaGFs
DQoNCg0KWzFdOiBodHRwOi8vd3d3LmxpbnV4LnNnaS5jb20vYXJjaGl2ZXMveGZzLzIwMTYtMDYv
bXNnMDAyOTkuaHRtbA==
WARNING: multiple messages have this Message-ID (diff)
From: "Verma, Vishal L" <vishal.l.verma@intel.com>
To: "lsf-pc@lists.linux-foundation.org" <lsf-pc@lists.linux-foundation.org>
Cc: "linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
"linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>
Subject: [LSF/MM TOPIC] Badblocks checking/representation in filesystems
Date: Fri, 13 Jan 2017 21:40:26 +0000 [thread overview]
Message-ID: <1484343558.4358.26.camel@intel.com> (raw)
The current implementation of badblocks, where we consult the badblocks
list for every IO in the block driver works, and is a last option
failsafe, but from a user perspective, it isn't the easiest interface to
work with.
A while back, Dave Chinner had suggested a move towards smarter
handling, and I posted initial RFC patches [1], but since then the topic
hasn't really moved forward.
I'd like to propose and have a discussion about the following new
functionality:
1. Filesystems develop a native representation of badblocks. For
example, in xfs, this would (presumably) be linked to the reverse
mapping btree. The filesystem representation has the potential to be
more efficient than the block driver doing the check, as the fs can
check the IO happening on a file against just that file's range. In
contrast, today, the block driver checks against the whole block device
range for every IO. On encountering badblocks, the filesystem can
generate a better notification/error message that points the user to
(file, offset) as opposed to the block driver, which can only provide
(block-device, sector).
2. The block layer adds a notifier to badblock addition/removal
operations, which the filesystem subscribes to, and uses to maintain its
badblocks accounting. (This part is implemented as a proof of concept in
the RFC mentioned above [1]).
3. The filesystem has a way of telling the block driver (a flag? a
different/new interface?) that it is responsible for badblock checking
so that the driver doesn't have to do its check. The driver checking
will have to remain in place as a catch-all for filesystems/interfaces
that don't or aren't capable of doing the checks at a higher layer.
Additionally, I saw some discussion about logical depop on the lists
again, and I was involved with discussions last year about expanding the
the badblocks infrastructure for this use. If that is a topic again this
year, I'd like to be involved in it too.
I'm also interested in participating in any other pmem/NVDIMM related
discussions.
Thank you,
-Vishal
[1]: http://www.linux.sgi.com/archives/xfs/2016-06/msg00299.html
_______________________________________________
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: "lsf-pc@lists.linux-foundation.org" <lsf-pc@lists.linux-foundation.org>
Cc: "linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
Subject: [LSF/MM TOPIC] Badblocks checking/representation in filesystems
Date: Fri, 13 Jan 2017 21:40:26 +0000 [thread overview]
Message-ID: <1484343558.4358.26.camel@intel.com> (raw)
The current implementation of badblocks, where we consult the badblocks
list for every IO in the block driver works, and is a last option
failsafe, but from a user perspective, it isn't the easiest interface to
work with.
A while back, Dave Chinner had suggested a move towards smarter
handling, and I posted initial RFC patches [1], but since then the topic
hasn't really moved forward.
I'd like to propose and have a discussion about the following new
functionality:
1. Filesystems develop a native representation of badblocks. For
example, in xfs, this would (presumably) be linked to the reverse
mapping btree. The filesystem representation has the potential to be
more efficient than the block driver doing the check, as the fs can
check the IO happening on a file against just that file's range. In
contrast, today, the block driver checks against the whole block device
range for every IO. On encountering badblocks, the filesystem can
generate a better notification/error message that points the user to
(file, offset) as opposed to the block driver, which can only provide
(block-device, sector).
2. The block layer adds a notifier to badblock addition/removal
operations, which the filesystem subscribes to, and uses to maintain its
badblocks accounting. (This part is implemented as a proof of concept in
the RFC mentioned above [1]).
3. The filesystem has a way of telling the block driver (a flag? a
different/new interface?) that it is responsible for badblock checking
so that the driver doesn't have to do its check. The driver checking
will have to remain in place as a catch-all for filesystems/interfaces
that don't or aren't capable of doing the checks at a higher layer.
Additionally, I saw some discussion about logical depop on the lists
again, and I was involved with discussions last year about expanding the
the badblocks infrastructure for this use. If that is a topic again this
year, I'd like to be involved in it too.
I'm also interested in participating in any other pmem/NVDIMM related
discussions.
Thank you,
-Vishal
[1]: http://www.linux.sgi.com/archives/xfs/2016-06/msg00299.html
next reply other threads:[~2017-01-13 21:40 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-13 21:40 Verma, Vishal L [this message]
2017-01-13 21:40 ` [LSF/MM TOPIC] Badblocks checking/representation in filesystems Verma, Vishal L
2017-01-13 21:40 ` Verma, Vishal L
[not found] <at1mp6pou4lenesjdgh22k4p.1484345585589@email.android.com>
[not found] ` <b9rbflutjt10mb4ofherta8j.1484345610771@email.android.com>
2017-01-14 0:00 ` 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 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 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=1484343558.4358.26.camel@intel.com \
--to=vishal.l.verma@intel.com \
--cc=linux-block@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.