[Cluster-devel] [PATCH 1/1 linux-next] GFS2: directly return gfs2_dir_check()
No need to store gfs2_dir_check result and test it before returning. Signed-off-by: Fabian Frederick f...@skynet.be --- fs/gfs2/inode.c | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/fs/gfs2/inode.c b/fs/gfs2/inode.c index c4ed823..b41b5c7 100644 --- a/fs/gfs2/inode.c +++ b/fs/gfs2/inode.c @@ -1045,11 +1045,7 @@ static int gfs2_unlink_ok(struct gfs2_inode *dip, const struct qstr *name, if (error) return error; - error = gfs2_dir_check(dip-i_inode, name, ip); - if (error) - return error; - - return 0; + return gfs2_dir_check(dip-i_inode, name, ip); } /** -- 1.9.3
Re: [Cluster-devel] [GFS2 PATCH] GFS2: Block reservation doubling scheme
- Original Message - - Original Message - This patch introduces a new block reservation doubling scheme. If we Maybe I sent this patch out prematurely. Instead of doubling the reservation, maybe I should experiment with making it grow additively. IOW, Instead of 32-64-128-256-512, I should use: 32-64-96-128-160-192-224-etc... I know other file systems using doubling schemes, but I'm concerned about it being too aggressive. I tried an additive reservations algorithm. I basically changed the previous patch from doubling the reservation to adding 32 blocks. In other words, I replaced: + ip-i_rsrv_minblks = 1; with this: + ip-i_rsrv_minblks += RGRP_RSRV_MINBLKS; The results were not as good, but still very impressive, and maybe acceptable: Reservation doubling scheme: EXTENT COUNT FOR OUTPUT FILES = 310103 EXTENT COUNT FOR OUTPUT FILES = 343990 EXTENT COUNT FOR OUTPUT FILES = 332818 EXTENT COUNT FOR OUTPUT FILES = 336852 EXTENT COUNT FOR OUTPUT FILES = 334820 Reservation additive scheme (32 blocks): EXTENT COUNT FOR OUTPUT FILES = 322406 EXTENT COUNT FOR OUTPUT FILES = 341665 EXTENT COUNT FOR OUTPUT FILES = 341769 EXTENT COUNT FOR OUTPUT FILES = 348676 EXTENT COUNT FOR OUTPUT FILES = 348079 So I'm looking for opinions: (a) Stick with the original reservation doubling patch, or (b) Go with the additive version. (c) Any other ideas? Regards, Bob Peterson Red Hat File Systems
