zap.h revision c7cd242109c82107ec2e50013369e92be9d77702
* The ZAP routines are thread-safe. However, you must observe the * DMU's restriction that a transaction may not be operated on * Any of the routines that return an int may return an I/O error (EIO * Implementation / Performance Notes: * The ZAP is intended to operate most efficiently on attributes with * short (49 bytes or less) names and single 8-byte values, for which * the microzap will be used. The ZAP should be efficient enough so * that the user does not need to cache these attributes. * The ZAP's locking scheme makes its routines thread-safe. Operations * on different zapobjs will be processed concurrently. Operations on * the same zapobj which only read data will be processed concurrently. * Operations on the same zapobj which modify data will be processed * concurrently when there are many attributes in the zapobj (because * the ZAP uses per-block locking - more than 128 * (number of cpus) * small attributes will suffice). * We're using zero-terminated byte strings (ie. ASCII or UTF-8 C * strings) for the names of attributes, rather than a byte string * bounded by an explicit length. If some day we want to support names * in character sets which have embedded zeros (eg. UTF-16, UTF-32), * we'll have to add routines for using length-bounded strings. * The matchtype specifies which entry will be accessed. * MT_EXACT: only find an exact match (non-normalized) * MT_FIRST: find the "first" normalized (case and Unicode * form) match; the designated "first" match will not change as long * as the set of entries with this normalization doesn't change * MT_BEST: if there is an exact match, find that, otherwise find the /* Use 64-bit hash value (serialized cursors will always use 64-bits) */ /* Key is binary, not string (zap_add_uint64() can be used) */ * First word of key (which must be an array of uint64) is * already randomly distributed. * Create a new zapobj with no attributes and return its object number. * MT_EXACT will cause the zap object to only support MT_EXACT lookups, * otherwise any matchtype can be used for lookups. * normflags specifies what normalization will be done. values are: * 0: no normalization (legacy on-disk format, supports MT_EXACT matching * U8_TEXTPREP_TOLOWER: case normalization will be performed. * regard to case (eg. looking for "foo" can find an entry "Foo"). * Eventually, other flags will permit unicode normalization as well. * Create a new zapobj with no attributes from the given (unallocated) * The zapobj passed in must be a valid ZAP object for all of the * Destroy this zapobj and all its attributes. * Frees the object number using dmu_object_free. * 'integer_size' is in bytes, and must be 1, 2, 4, or 8. * Retrieve the contents of the attribute with the given name. * If the requested attribute does not exist, the call will fail and * If 'integer_size' is smaller than the attribute's integer size, the * call will fail and return EINVAL. * If 'integer_size' is equal to or larger than the attribute's integer * size, the call will succeed and return 0. * When converting to a * larger integer size, the integers will be treated as unsigned (ie. no * sign-extension will be performed). * 'num_integers' is the length (in integers) of 'buf'. * If the attribute is longer than the buffer, as many integers as will * fit will be transferred to 'buf'. If the entire attribute was not * transferred, the call will return EOVERFLOW. * If rn_len is nonzero, realname will be set to the name of the found * entry (which may be different from the requested name if matchtype is * If normalization_conflictp is not NULL, it will be set if there is * another name with the same case/unicode normalized form. * Create an attribute with the given name and value. * If an attribute with the given name already exists, the call will * fail and return EEXIST. * Set the attribute with the given name to the given value. If an * attribute with the given name does not exist, it will be created. If * an attribute with the given name already exists, the previous value * will be overwritten. The integer_size may be different from the * existing attribute's integer size, in which case the attribute's * integer size will be updated to the new value. * Get the length (in integers) and the integer size of the specified * If the requested attribute does not exist, the call will fail and * Remove the specified attribute. * If the specified attribute does not exist, the call will fail and * Returns (in *count) the number of attributes in the specified zap * Returns (in name) the name of the entry whose (value & mask) * (za_first_integer) is value, or ENOENT if not found. The string * pointed to by name must be at least 256 bytes long. If mask==0, the * match must be exact (ie, same as mask=-1ULL). * Transfer all the entries from fromobj into intoobj. Only works on * int_size=8 num_integers=1 values. Fails if there are any duplicated /* Same as zap_join, but set the values to 'value'. */ /* Same as zap_join, but add together any duplicated entries. */ * Manipulate entries where the name + value are the "same" (the name is * a stringified version of the value). /* Here the key is an int and the value is a different int. */ * They name is a stringified version of key; increment its value by * delta. Zero values will be zap_remove()-ed. /* This structure is opaque! */ * za_normalization_conflict will be set if there are additional * entries with this normalized form (eg, "foo" and "Foo"). * The interface for listing all the attributes of a zapobj can be * thought of as cursor moving down a list of the attributes one by * one. The cookie returned by the zap_cursor_serialize routine is * persistent across system calls (and across reboot, even). * Initialize a zap cursor, pointing to the "first" attribute of the * zapobj. You must _fini the cursor when you are done with it. * Get the attribute currently pointed to by the cursor. Returns * ENOENT if at the end of the attributes. * Advance the cursor to the next attribute. * Get a persistent cookie pointing to the current position of the zap * cursor. The low 4 bits in the cookie are always zero, and thus can * be used as to differentiate a serialized cookie from a different type * of value. The cookie will be less than 2^32 as long as there are * fewer than 2^22 (4.2 million) entries in the zap object. * Advance the cursor to the attribute having the given key. * Initialize a zap cursor pointing to the position recorded by * zap_cursor_serialize (in the "serialized" argument). You can also * use a "serialized" argument of 0 to start at the beginning of the * zapobj (ie. zap_cursor_init_serialized(..., 0) is equivalent to * Size of the pointer table (in number of entries). * This is always a power of 2, or zero if it's a microzap. * In general, it should be considerably greater than zs_num_leafs. * The number of blocks used. Note that some blocks may be * wasted because old ptrtbl's and large name/value blocks are * not reused. (Although their space is reclaimed, we don't * reuse those offsets in the object.) * Pointer table values from zap_ptrtbl in the zap_phys_t * Values of the other members of the zap_phys_t * Histograms. For all histograms, the last index * (ZAP_HISTOGRAM_SIZE-1) includes any values which are greater * than what can be represented. For example * zs_leafs_with_n5_entries[ZAP_HISTOGRAM_SIZE-1] is the number * of leafs with more than 45 entries. * zs_leafs_with_n_pointers[n] is the number of leafs with * zs_leafs_with_n_entries[n] is the number of leafs with * [n*5, (n+1)*5) entries. In the current implementation, there * can be at most 55 entries in any block, but there may be * fewer if the name or value is large, or the block is not * zs_leafs_n_tenths_full[n] is the number of leafs whose * fullness is in the range [n/10, (n+1)/10). * zs_entries_using_n_chunks[n] is the number of entries which * consume n 24-byte chunks. (Note, large names/values only use * one chunk, but contribute to zs_num_blocks_large.) * zs_buckets_with_n_entries[n] is the number of buckets (each * leaf has 64 buckets) with n entries. * zs_buckets_with_n_entries[1] should be very close to * Get statistics about a ZAP object. Note: you need to be aware of the * internal implementation of the ZAP to correctly interpret some of the * statistics. This interface shouldn't be relied on unless you really * know what you're doing.