| Message ID | 20201230165601.845024-3-ruansy.fnst@cn.fujitsu.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | fsdax: introduce fs query to support reflink | expand |
It happens on a dax_device. We should not interwind dax and block_device even more after a lot of good work has happened to detangle them.
On Fri, Jan 08, 2021 at 10:55:00AM +0100, Christoph Hellwig wrote: > It happens on a dax_device. We should not interwind dax and block_device > even more after a lot of good work has happened to detangle them. I agree that the dax device should not be implied from the block device, but what happens if regular block device drivers grow the ability to (say) perform a background integrity scan and want to ->corrupted_range? --D
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h index 033eb5f73b65..45256fe84fa7 100644 --- a/include/linux/blkdev.h +++ b/include/linux/blkdev.h @@ -1858,6 +1858,8 @@ struct block_device_operations { int (*report_zones)(struct gendisk *, sector_t sector, unsigned int nr_zones, report_zones_cb cb, void *data); char *(*devnode)(struct gendisk *disk, umode_t *mode); + int (*corrupted_range)(struct gendisk *disk, struct block_device *bdev, + loff_t offset, size_t len, void *data); struct module *owner; const struct pr_ops *pr_ops; };
In fsdax mode, the memory failure happens on block device. So, it is needed to introduce an interface for block devices. Each kind of block device can handle the memory failure in ther own ways. Signed-off-by: Shiyang Ruan <ruansy.fnst@cn.fujitsu.com> --- include/linux/blkdev.h | 2 ++ 1 file changed, 2 insertions(+)