On Fri, May 26, 2017 at 12:49:25PM -0700, Liu Bo wrote: > On Fri, May 26, 2017 at 07:08:31PM +0200, David Sterba wrote: > > On Thu, May 25, 2017 at 06:39:52AM -0400, Jeff Layton wrote: > > > Nothing checks its return value. > > > > I think we don't need to check the return value of > > filemap_fdatawait_range, because the errors are tracked by other means > > (attached to the btree_inode mapping that represents the metadata), in > > set_btree_ioerr. > > > > > Signed-off-by: Jeff Layton <jlayton@xxxxxxxxxx> > > > Reviewed-by: Jan Kara <jack@xxxxxxx> > > > Reviewed-by: Liu Bo <bo.li.liu@xxxxxxxxxx> > > > > To Liu Bo: > > > > May I ask if you did a review that matches the above understanding? It's > > trivial to see that nothing really checks the return value of > > btrfs_wait_tree_block_writeback but my question is if it's really safe > > not to so. Thanks. > > About the question if it's safe not to do so, I think yes, it's used in > walk_log_tree which is called in two places, free_log_tree and log replay. For > free_log_tree, it waits for any running writeback of the extent buffer under > freeing to finish in case we need to access the eb pointer from page->private, > and it's OK to not check the return value, while for log replay, it's doesn't > wait because wc->wait is not set. So neither cares about the writeback error. Thanks, I'll update the changelog. -- 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
