Re: common layout xattr

[Andreas Dilger <adilger@sun.com>]

On Jul 15, 2009  15:19 -0700, Sage Weil wrote:
> On Wed, 15 Jul 2009, Andreas Dilger wrote:
> > I'm thinking of using simple ASCII key=value pairs to store basic
> > layout information like chunk size, stripe count, mirror count,
> > RAID type, etc.  Some of them may not be applicable/usable by all
> > filesystems, but having a handful of "well known" keys and values
> > for a common xattr name would at least be better than what we have
> > now (which is nothing).
> > 
> > Something like (not necessarily a firm proposal yet):
> > 
> > trusted.common_layout:
> > chunk_bytes=65536
> > stripe_count=32
> > mirror_count=3
> > raid_type=1+0
> > 
> > Is this something you would be interested to pursue?  I've also discussed
> > this with Panasas, and they had some interest in this as well.  Any GPFS
> > developers watching?
> 
> This sounds like a good idea to me.  I think the main hurdle is going to 
> be defining a generalized layout description that captures all the full 
> space of layouts for each file systems, and also translates gracefully 
> between them.  IIRC Lustre, for instance, will stripe over $stripe_count 
> objects, while Ceph (and Panasas?) will stripe up to some $max_object_size 
> and then move on to a new set of objects.  Or stagger chunk order in 
> successive stripes, etc.

Well, I don't think we can capture all of the details for every
filesystem, but I'm hoping we can get some of the main parameters
working.  Having additional attributes that are more filesystem
specific is fine too (to a reasonable extent of course).

For parts of the layout that are generated programatically, like the
Ceph/Panasas striping order, I don't think that has to be encoded
explicitly into the layout xattr, since I'd assume the pattern is
always the same between files (e.g. use $stripe_count objects until
$max_object_size bytes, then a different set of $stripe_count objects
for $max_object_size bytes).  That Lustre uses the same $stripe_count
objects for the whole file, and it would ignore $max_object_size is
below the level of detail that I'm currently interested in.  In the
reverse direction, I'd assume that Ceph/Panasas would fill in the
value for $max_object_size from a default, as if no layout was used.


Filesystems are free to ignore parameters they don't like, and/or save them
and return them again when asked (probably with a flag that indicates they
are not currently in use), basically treating them as an opaque user xattr.
This will preserve the settings across an fsX -> fsY -> fsX transfer.

Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.