From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Price Date: Mon, 12 Oct 2015 18:14:25 +0100 Subject: [Cluster-devel] [PATCH] libgfs2: Return the rgrp count in lgfs2_rgrps_plan() In-Reply-To: <1169191743.44604397.1444664857224.JavaMail.zimbra@redhat.com> References: <1444663364-6364-1-git-send-email-anprice@redhat.com> <1169191743.44604397.1444664857224.JavaMail.zimbra@redhat.com> Message-ID: <561BEA71.7070202@redhat.com> List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Bob, On 12/10/15 16:47, Bob Peterson wrote: > ----- Original Message ----- >> lgfs2_rgrps_plan() previously returned one of the rgrp sizes >> specifically so that gfs2_grow could check it. This check was also done >> inside the function so the return value would always be 0 when the rgrp >> size was too small anyway (really this means that there's not enough >> space in which to place sensibly sized rgrps). As returning 0 is >> sufficient to pass back the same information, we can return the resource >> group count from lgfs2_rgrps_plan() instead, as that is a more useful >> value in general. >> > Hi Andy, > > Does this all work with a tiny file system that only has one resource group? > I remember trying to code similar things and Abhi kept having to fix it > because of problems with single-rgrp file systems. Bear in mind, I haven't > looked at the rest of this function in detail, so I'm speaking somewhat out > of ignorance. I'm not sure which problems you're referring to to test for them but this patch is essentially cosmetic so it doesn't change the behaviour of mkfs.gfs2 nor gfs2_grow. I have done various tests with small file systems since the lgfs2_rgrp* functions were introduced though and they've held up well (or have been fixed), and those functions are well-covered by the test suite. That said, to double-check I've created a 9M fs (minimum journal size is 8M) and ran a successful mount-fill-umount-fsck-mount-grow-umount-fsck test on it. The initial resource groups were obviously tiny (ri_length = 1) but the ones gfs2_grow added were much larger, which is expected as lgfs2_rgrps_plan() doesn't use the existing rgrps' sizes in its calculations. Cheers, Andy