Whamcloud - gitweb
Add new LOV EA format which gives us fields for features needed in the post
authoradilger <adilger>
Mon, 27 Oct 2003 19:34:19 +0000 (19:34 +0000)
committeradilger <adilger>
Mon, 27 Oct 2003 19:34:19 +0000 (19:34 +0000)
commitfceeeb07e01228eb42d51dea244db2a1a09c53fc
tree7e8a44457b5b1398766c3430224d00ccc3f20f54
parent21ea76cd2212551605821dbf0b40077b8513c52a
Add new LOV EA format which gives us fields for features needed in the post
1.0 stage (e.g. RAID, OST migration/replacement) as well as more efficient
storage than the current layout when there are few stripes on lots of OSTs.
As well, we will now be able to back up/restore/manipulate EA data via the
"getfattr" and "setfattr" tools (attr RPM) that are part of EA tools from
the "trusted.lov" attribute (only accessible to root/priviledged users).

Also contains code to transparently migrate from old EA format to new one
the first time the EA is accessed.  Note that there is no going back to old
code on the same filesystem once the EAs have been updated.  EA conversion
is (hopefully) "fail safe" in that an error during conversion just means
that the on-disk EA is kept in old format (clients understand both because of
common code).

Some of the "compat" code can be removed once we hit 1.0 and users have
migrated, but the infrastructure itself should probably remain for the
next time we need to change the EA format.

This also adds "lustre_user.h" which was in b_llp_hp and has existed in
b_llnl for some time, but alas the user EA format had to change in order
to allow specification of striping format.  A recompile should fix it.

Some minor warts remain:
- mds_objids_from_lmm() knows too much about lmm format.  It had an existing
  bug (looping to ld_tgt_count vs lmm_ost_count) and caused another bug for
  me because it does its own unpacking of the lmm) and it would be nice to
  just get rid of it and use obd_unpackmd(lmm) to get an lsm instead and use
  that instead of "ids"
- need to fix up endianness from ll_lov_setstripe() because this is now not
  done on the same host any more (object creation is done on MDS now)
- liblustreapi() should not be doing the printing of structs, but should
  instead just return structs to user-space and/or using a callback function
  supplied by the caller (e.g. for lfind iterating over filesystem).  The
  lov_dump_user_lmm* functions should probably be exported from the library
  and be used as default print functions as a starting point.
b=2097
r=braam
lustre/lov/lov_internal.h
lustre/mds/mds_internal.h
lustre/utils/liblustreapi.c