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, -liubo -- 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
