----- Original Message ----- | On 01/12/17 17:34, Bob Peterson wrote: | > Hi, | > | > Before this patch, tiny function gfs2_log_write called small function | > gfs2_log_bmap to determine which journal block to write. If function | > gfs2_log_bmap encountered a problem in its block mapping calculations, | > it would return a block number of -1 to indicate an error. This error | > was immediately ignored and forgotten: the caller went ahead and | > tried to write to the log anyway. This patch fixes the problem | > by checking the results of the block map calculations and doing | > an assert withdraw if an error occurs. It also eliminates function | > gfs2_log_bmap in favor of inlining the code to make the code more | > readable. | > | > This should improve overall journal integrity, as a precursor to | > log writing improvements we are planning. | Again, I'm not sure that there is anything to be gained in readability | by inlining gfs2_log_bmap(). Why not just add the new error check in | that function? | | Steve.
As explained in my previous email: "Death by a thousand cuts." I much prefer the readability of one 17-line function to two functions of 9 lines each. Bob Peterson
