Re: [PATCH v4 0/2] vfs: have syncfs() return error when there are writeback errors
From: Jeff Layton <jlayton@kernel.org>
Date: 2020-03-03 13:10:25
Also in:
linux-fsdevel, lkml
On Thu, 2020-02-13 at 16:02 -0500, Jeff Layton wrote:
v4: - switch to dedicated errseq_t cursor in struct file for syncfs - drop ioctl for fetching the errseq_t without syncing This is the fourth posting of this patchset. After thinking about it more, I think multiplexing file->f_wb_err based on O_PATH open is just too weird. I think it'd be better if syncfs() "just worked" as expected no matter what sort of fd you use, or how you multiplex it with fsync. Also (at least on x86_64) there is currently a 4 byte pad at the end of the struct so this doesn't end up growing the memory utilization anyway. Does anyone object to doing this? I've also dropped the ioctl patch. I have a draft patch to expose that via fsinfo, but that functionality is really separate from returning an error to syncfs. We can look at that after the syncfs piece is settled. Jeff Layton (2): vfs: track per-sb writeback errors and report them to syncfs buffer: record blockdev write errors in super_block that it backs drivers/dax/device.c | 1 + fs/buffer.c | 2 ++ fs/file_table.c | 1 + fs/open.c | 3 +-- fs/sync.c | 6 ++++-- include/linux/fs.h | 16 ++++++++++++++++ include/linux/pagemap.h | 5 ++++- 7 files changed, 29 insertions(+), 5 deletions(-)
Hi Al, Wondering if you've had a chance to look at these yet? I think it makes sense -- the only part I'm not sure about is adding a field to struct file. That ends up inside the 4-byte pad at the end on x86_64, so my hope is that that's not a problem. If you're too busy at the moment, then maybe Andrew can help shepherd this in instead? Thanks, -- Jeff Layton [off-list ref]