From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bob Peterson Date: Thu, 24 Jan 2019 13:32:32 -0500 (EST) Subject: [Cluster-devel] [PATCH] gfs2: Fix loop in gfs2_rbm_find (2) In-Reply-To: <1511413108.66711908.1548351783052.JavaMail.zimbra@redhat.com> References: <20190124155758.9741-1-agruenba@redhat.com> <1511413108.66711908.1548351783052.JavaMail.zimbra@redhat.com> Message-ID: <1104605356.66722605.1548354752398.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 ----- > ----- Original Message ----- > > The fix from commit 2d29f6b96d8f introduced an unexpected performance > > regression when allocating blocks. Fix by rewriting the overly > > complicated wrap-around logic in gfs2_rbm_find in a more reasonable way. > > Discovered and verified with iozone. > > > > Fixes: 2d29f6b96d8f ("gfs2: Fix loop in gfs2_rbm_find") > > Cc: stable at vger.kernel.org # v3.13+ > > Signed-off-by: Andreas Gruenbacher (snip) > With this new patch, it will just go back next_bitmap, but there are no more > bitmaps. It sets wrap, but since we're at the end, it returns -ENOSPC, when, > in fact, there is a free block, no? On closer inspection, the patch looks okay to me. I still want to test it before we push it. Bob Peterson