On Jul 16, 2009 15:29 -0700, Sage Weil wrote: > 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. The filesystem pretty much has to do that already, because currently no layout information is passed to the filesystem with the majority of file creates. > 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) Hmm, I thought Ceph had replication for files? "mirror_count" was intended to indicate the number of copies of that file that are maintained. Maybe it needs a better name? > 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) Exactly what I was thinking. > How would you indicate which parameters are being ignored? Something > easily parsed (and ignored) when setting the xattr. I was just thinking something like a prefix or postfix character: chunk_bytes=65536 stripe_count=32 mirror_count=3 raid_type=1+0 *max_object_size=64MB or max_object_size=64MB* It might also make sense to use "*" (or some other character) to indicate values that are the filesystem-wide default values, and not store them either, but that isn't a well-formed opinion yet. Even dynamically-added "comments" might be OK, like: chunk_bytes=65536 # default stripe_count=32 # default mirror_count=3 raid_type=1+0 # default max_object_size=64MB # unknown > As long as the common parameter names are somewhat standardized, this > seems straightforward enough. Good, I don't want anything too complex. Cheers, Andreas -- Andreas Dilger Sr. Staff Engineer, Lustre Group Sun Microsystems of Canada, Inc. -- 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
