[gpfsug-discuss] Multiple Block Sizes in a Filesystem (Was: Online data migration tool)

[Aaron Knister]

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