On Thu, 16 Jul 2009, Andreas Dilger wrote: > 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. The fs would need to add in any unspecified local settings with defaults, so that in general reading the xattr will still always fully describe the layout. So in your example, on fsX (Lustre) you might see chunk_bytes=65536 stripe_count=32 mirror_count=3 raid_type=1+0 On fsY (ceph) you might see chunk_bytes=65536 stripe_count=32 mirror_count=3 (ceph ignores) raid_type=1+0 (ceph ignores) max_object_size=64MB (ceph adds) and back on fsX (Lustre) you'd get chunk_bytes=65536 stripe_count=32 mirror_count=3 raid_type=1+0 max_object_size=64MB (lustre ignores) How would you indicate which parameters are being ignored? Something easily parsed (and ignored) when setting the xattr. As long as the common parameter names are somewhat standardized, this seems straightforward enough. sage -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
