From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bob Peterson Date: Mon, 4 Dec 2017 09:33:05 -0500 (EST) Subject: [Cluster-devel] [GFS2 PATCH] GFS2: Fix gfs2_log_write and eliminate gfs2_log_bmap In-Reply-To: <2c3401fc-12cc-1af2-fc25-818a22a15c40@redhat.com> References: <487120039.37168024.1512149649698.JavaMail.zimbra@redhat.com> <2c3401fc-12cc-1af2-fc25-818a22a15c40@redhat.com> Message-ID: <234147738.38091705.1512397985362.JavaMail.zimbra@redhat.com> List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit ----- 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