I was thinking some more about the >32 subblock feature in scale 5.0. As mentioned by IBM the biggest advantage of that feature is on filesystems with large blocks (e.g. multiple MB). The majority of our filesystems have a block size of 1MB which got me thinking... wouldn't it be nice if they had a larger block size (there seem to be compelling performance reasons for large file I/O to do this).
I'm wondering, what's the feasibility is of supporting filesystem pools of varying block sizes within a single filesystem? I thought allocation maps exist on a per-pool basis which gives me some hope it's not too hard. If one could do this then, yes, you'd still need new hardware to migrate to a larger block size (and >32 subblocks), but it could be done as part of a refresh cycle *and* (and this is the part most important to me) it could be driven entirely by the policy engine which means storage admins are largely hands off and the migration is by and large transparent to the end user. This doesn't really address the need for a tool to address a filesystem migration to 4k metadata blocks (although I wonder if something could be done to create a system_4k pool that contains 4k-aligned metadata NSDs where key data structures get re-written during a restripe in a 4k-aligned manner, but that's really grasping at straws for me). -Aaorn -- Aaron Knister NASA Center for Climate Simulation (Code 606.2) Goddard Space Flight Center (301) 286-2776 _______________________________________________ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss
