On Fri, 2017-06-16 at 15:34 -0400, Jeff Layton wrote:
> Jan Kara's description for this patch is much better than mine, so I'm
> quoting it verbatim here:
>
> DAX currently doesn't set errors in the mapping when cache flushing
> fails in dax_writeback_mapping_range(). Since this function can get
> called only from fsync(2) or sync(2), this is actually as good as it can
> currently get since we correctly propagate the error up from
> dax_writeback_mapping_range() to filemap_fdatawrite()
>
> However, in the future better writeback error handling will enable us to
> properly report these errors on fsync(2) even if there are multiple file
> descriptors open against the file or if sync(2) gets called before
> fsync(2). So convert DAX to using standard error reporting through the
> mapping.
>
> Signed-off-by: Jeff Layton <jlayton@xxxxxxxxxx>
> Reviewed-by: Jan Kara <jack@xxxxxxx>
> Reviewed-by: Christoph Hellwig <hch@xxxxxx>
> Reviewed-and-Tested-by: Ross Zwisler <ross.zwisler@xxxxxxxxxxxxxxx>
> ---
> fs/dax.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/fs/dax.c b/fs/dax.c
> index 9899f07acf72..c663e8cc2a76 100644
> --- a/fs/dax.c
> +++ b/fs/dax.c
> @@ -856,8 +856,10 @@ int dax_writeback_mapping_range(struct address_space *mapping,
>
> ret = dax_writeback_one(bdev, dax_dev, mapping,
> indices[i], pvec.pages[i]);
> - if (ret < 0)
> + if (ret < 0) {
> + mapping_set_error(mapping, ret);
> goto out;
> + }
> }
> }
> out:
I should point out here that Ross had an issue with this patch in an
earlier set, that I addressed with a flag in the last set. The flag is
icky though.
In this set, patch #6 should make it unnecessary:
mm: clear AS_EIO/AS_ENOSPC when writeback initiation fails
Ross, could you test that this set still works ok for you with dax? It
should apply reasonably cleanly on top of linux-next.
Thanks,
--
Jeff Layton <jlayton@xxxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
