sys/vfs/hammer: Remove signature from ondisk node The node signature was added in the early stage of hammer development, but it's no longer used for anything except that newfs_hammer sets the field to GOOD (for no reason). c461935c added some code to propagate the GOOD signature on node split (just to make it look a bit more sane), but it's useless anyway. This commit changes the signature field to reserved00, and also gets rid of HAMMER_BTREE_SIGNATURE_XXX macros. The change doesn't affect anything just like c461935c did nothing good or bad.
sys/vfs/hammer: Adjust raw kprintfs using hkprintf variants This is part3 of hkprintf related after the following two. sys/vfs/hammer: Change hkprintf() to macro and add variants [2/2] sys/vfs/hammer: Change hkprintf() to macro and add variants [1/2] Above two commits have replaced the existing kprintf calls using "HAMMER:" or "HAMMER(label)" or function name prefix with hkprintf and newly added variants, which basically didn't change actual output other than fixing wrong function names to the right ones, etc. This commit continues replacing remaining kprintfs to make output more understandable than raw kprintf calls with no clue that they're hammer related. For example, an error message like "BIGBLOCK UNDERFLOW\n" or a debug message like "rt %3u, xt %3u, tt %3u\n" become more understanbale with "HAMMER:" prefix or the name of the function. This commit is based on the followings. 1. Use hdkprintf which is hkprintf variant with __func__ prefix if that kprintf call is used when vfs.hammer.debug_xxx is enabled. This implies the messages are only for debugging and those are usually better and more understandable with a function name prefix as mentioned above. Also this is what's been done mostly in the existing hammer code. 2. Use hkprintf which has "HAMMER:" prefix if that kprintf call is a regular hammer message that appears in regular filesystem operations such as "Formatting of valid HAMMER volume %s denied. Erase with dd!\n". 3. Use h[vm]kprintf which are hkprintf variants with hammer label prefix "HAMMER(label)" if that kprintf can safely access the label via vol or hmp pointer. Some kprintfs in hammer does this rather than just "HAMMER:" and this seems to be better, however this commit doesn't go far as to aggressively replace the existing ones with this because a caller safely dereferencing hmp or vol is a different topic from merely replacing.
sys/vfs/hammer: Add hpanic() [1/2] This commit does the following. 1. Add a macro hpanic() which is a wrapper for panic() that embed the following prefix. "function_name: ..." 2. Replace raw panic() calls that have above prefix with hpanic(). 3. Fix some wrong function name literals using __func__.
sys/vfs/hammer: Change hkprintf() to macro and add variants [2/2] This commit does the following. 1. Add macros hdkprintf() and hdkrateprintf() that embed the following prefix. "function_name: ..." 2. Replace raw kprintf() calls that have above prefix with newly added macros. 3. Fix some wrong function name literals using __func__.
sys/vfs/hammer: Change hkprintf() to macro and add variants [1/2] This commit does the following. 1. Remove an inline function hkprintf(). 2. Add a macro version of hkprintf() and its variants that embed the following prefix. "HAMMER: ..." "HAMMER(label) ..." 3. Replace raw kprintf() calls that have above prefix with newly added macros. hkprintf() macro doesn't use hammer_debug_debug flag that was used by the inline function version of hkprintf(), but this doesn't make much difference from the way hkprintf() and hammer_debug_debug have been used.
sys/vfs/hammer: Erase btype of a new boundary on internal split It's more sane to erase btype of RBN of the original node on internal split than only erasing subtree_offset. (subtree_offset==0 means the elm has no child, but btype not being 0 means its child is either leaf or internal node which is insane if not a bug) This doesn't affect comparison of nodes because btype is not a part of keys to determine > or = or < of nodes. This also makes possible to write non-ambiguous test code in userspace as it eliminates multiple possible ways that test code needs to deal with and be more explicit, which is considered a good thing if the kernel change doesn't degrade performance, etc. Also see 6580f642.
sys/vfs/hammer: Rename btree_set_parent() to btree_set_parent_of_child() This commit renames btree_set_parent() to btree_set_parent_of_child() since btree_set_parent() is counter-intuitive. 1. btree_get_parent(node) returns node's parent, but 2. btree_set_parent(node, elm) sets its child's parent to node instead of setting node's parent to something, which isn't quite expected behavior from the way these two functions are named.
sys/vfs/hammer: Remove redundant elm type check [1/2] hammer_btree_lock_children() assumes the node is internal, but not leaf or anything else. Also given that all elms[] within a node has the same elm type (i.e. all elms[] use the same union member of hammer_btree_elm_t), this function doesn't need to check if each elms[i] is a node element of an internal node. If elms[] are not elements of an internal node, then the caller is not using this function right rather than this function missing sanity checks. In fact this is (only)used by hammer_split_internal() and reblock/rebalance code where they deal with internal nodes. They all do pass an internal node.
sys/vfs/hammer: Don't return 0 on invalid elm.leaf.base.btype A leaf node only has records without any boundary elm, so btype is always RECORD, anything else is invalid. (There used to be several other types that no longer exist that could be set to elm.leaf.base.btype)
sys/vfs/hammer: Properly access node element base elm should dereference leaf.base instead of internal.base since the node that contains node elm here is a leaf node. These two refer to the same address, but the leaf.base is the right one in terms of code. Also print elm->leaf.base.btype which is always expected to be 'R'.
sys/vfs/hammer: Simplify hammer_print_btree_elm() Given that the purpose of hammer_print_btree_elm() is to print a node elm info that points to a node (but not a node info that contains the node elm), it's better not to have any external info such as node type and elm index as a part of arguments.
sys/vfs/hammer: Add hammer_is_internal|leaf_node_elm() The data structure of each elm of node::elms[63] (elms[62] for internal node excluding boundary) is simply determined by the type of node that contains node::elms[63]. This makes code like (A) very clear and straight forward, but makes code like (B) not clear because what elms point to can not be simply determined by the node type. Adding inline functions hammer_is_internal|leaf_elm() as shown in (C), which essentialy do the same thing, makes code look as straight forward as (A). There are several situations where hammer wants to find out if the given elm is an element within an internal node, and hammer_is_internal_elm() can make such code more clear than using switch(elm.base.btype). These functions are only used in btree search/iteration related code. Using these inline functions doesn't affect performance. Also see the next commit which is related to this and the previous commit. ===== (A) elm = &node->elms[i]; switch (node->type) { case HAMMER_BTREE_TYPE_INTERNAL: /* case matches union member */ elm->internal.subtree_offset... break; case HAMMER_BTREE_TYPE_LEAF: /* case matches union member */ elm->leaf.data_offset... break; } ===== ===== (B) elm = &node->elms[i]; switch (elm->base.btype) { case HAMMER_BTREE_TYPE_INTERNAL: case HAMMER_BTREE_TYPE_LEAF: /* this is right but not obvious */ elm->internal.subtree_offset... break; case HAMMER_BTREE_TYPE_RECORD: /* this is right but not obvious */ elm->leaf.data_offset... break; } ===== ===== (C) elm = &node->elms[i]; if (hammer_is_internal_node_elm(elm)) { elm->internal.subtree_offset... } else { /* or else if (hammer_is_leaf_node_elm(elm)) { */ elm->leaf.data_offset... } =====
sys/vfs/hammer: Fix wrong node type in switch/case A node type is either internal or leaf (or deleted which is originally internal or leaf), but not record. A node element's btype could be internal, leaf or record, but hammer_print_btree_node() is passing a node type to this function, so cases must be either internal or leaf. hammer_print_btree_node() and hammer_print_btree_elm() are not used so nothing changes anyway.