zfs code - Dec 2007 - New ZAP object based on Micro-ZAP

Hi,
	While using DMU for lustre we need to store some extra information in
directory entries which is required for lustre operations. The size of
typical entries to be stored in directory entries are 16 bytes, hence we
can''t use micro zap. And we would like to avoid using fat zap as not
many entries will be stored.
	Hence we thought about implementing a new ZAP object, something based
on mzap where all fields except the value field are the same. The format
would be something like this :

		typedef struct new_mzap_ent_phys {
		        uint64_t new_mze_value[2];
		        uint32_t new_mze_cd;
		        uint16_t new_mze_pad;       /* in case we want to chain them
someday */
		        char new_mze_name[NEW_MZAP_NAME_LEN];
		} new_mzap_ent_phys_t;

#define NEW_MZAP_LEN 	64
#define NEW_MZAP_NAME_LEN (NEW_MZAP_LEN - 16 - 4 - 2)

Comments/Suggestions about it are most welcome.

Thanks & Regards,
Girish

Girish Shilamkar wrote:
> Hi,
> 	While using DMU for lustre we need to store some extra information in
> directory entries which is required for lustre operations. The size of
> typical entries to be stored in directory entries are 16 bytes, hence we
> can''t use micro zap. And we would like to avoid using fat zap as
not
> many entries will be stored.
> 	Hence we thought about implementing a new ZAP object, something based
> on mzap where all fields except the value field are the same. The format
> would be something like this :
> 
> 		typedef struct new_mzap_ent_phys {
> 		        uint64_t new_mze_value[2];
> 		        uint32_t new_mze_cd;
> 		        uint16_t new_mze_pad;       /* in case we want to chain them
> someday */
> 		        char new_mze_name[NEW_MZAP_NAME_LEN];
> 		} new_mzap_ent_phys_t;
> 
Sounds reasonable to me.

--matt