[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1497539004.4607.7.camel@redhat.com>
Date: Thu, 15 Jun 2017 11:03:24 -0400
From: Jeff Layton <jlayton@...hat.com>
To: Christoph Hellwig <hch@...radead.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Al Viro <viro@...IV.linux.org.uk>, Jan Kara <jack@...e.cz>,
tytso@....edu, axboe@...nel.dk, mawilcox@...rosoft.com,
ross.zwisler@...ux.intel.com, corbet@....net,
Chris Mason <clm@...com>, Josef Bacik <jbacik@...com>,
David Sterba <dsterba@...e.com>,
"Darrick J . Wong" <darrick.wong@...cle.com>,
linux-fsdevel@...r.kernel.org, linux-mm@...ck.org,
linux-ext4@...r.kernel.org, linux-xfs@...r.kernel.org,
linux-btrfs@...r.kernel.org, linux-block@...r.kernel.org
Subject: Re: [PATCH v6 12/20] fs: add a new fstype flag to indicate how
writeback errors are tracked
On Thu, 2017-06-15 at 07:57 -0700, Christoph Hellwig wrote:
> On Thu, Jun 15, 2017 at 06:42:12AM -0400, Jeff Layton wrote:
> > Correct.
> >
> > But if there is a data writeback error, should we report an error on all
> > open fds at that time (like we will for fsync)?
>
> We should in theory, but I don't see how to properly do it. In addition
> sync_file_range just can't be used for data integrity to start with, so
> I don't think it's worth it. At some point we should add a proper
> fsync_range syscall, though.
filemap_report_wb_err will always return 0 if the inode never has
mapping_set_error called on it. So, I think we should be able to do it
there once we get all of the fs' converted over. That'll have to happen
at the end of the series however.
--
Jeff Layton <jlayton@...hat.com>
Powered by blists - more mailing lists