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��.n��������+%����;��w��{.n�����{���)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
