----- 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
