hammer - HAMMER Version 7 * Add support for version 7 which changes the CRC mechanic from the old slow CRC code to the faster ISCSI CRC code. We don't use the CRC instruction yet but ths base ISCSI CRC from FreeBSD is 6x faster than the CRC code we were using before. * Change newfs_hammer default to version 7 (for master).
hammer - Try to fix improper DATA CRC error * Under heavy I/O loads HAMMER has an optimization (similar to UFS) where the logical buffer is used to issue a write to the underlying device, rather than copying the logical buffer to a device buffer. This optmization is earmarked by a hammer2_record. * If the logical buffer is discarded just after it is written, and then re-read, hammer may go through a path which calls hammer_ip_resolve_data(). This code failed to check whether the record was still in-progress, and in-fact the write to the device may not have even been initiated yet, and there could also have been a device buffer alias in the buffer cache for the device for the offset. This caused the followup read to access the wrong data, causing HAMMER to report a DATA CRC error. The actual media receives the correct data eventually and a umount/remount would show an uncorrupted file. * Try to fix the problem by calling hammer_io_direct_wait() on the record in this path to wait for the operation to complete (and also to invalidate the related device buffer) before trying to re-read the block from the media.
sys/vfs/hammer: Add warning messages on ENOSPC Add warning messages if the blockmap allocator finds ENOSPC. B-Tree functions may also return ENOSPC, but those are results of failure in blockmap allocation on node split. _hammer_checkspace() doesn't have this warning for now. This gets called by many of the syscalls before inmemory/ondisk file operations start, so it's pretty obvious without bunch of "No space left" in dmesg.
sys/vfs/hammer: Add hammer_btree_extract_data() [2/2] This commit replaces hammer_btree_extract(cursor, HAMMER_CURSOR_GET_DATA) with hammer_btree_extract_data(&cursor) which are the remaining ones from the previous commit. From the way hammer_btree_extract_data() is implemented, hammer_btree_extract(cursor, HAMMER_CURSOR_GET_DATA) is the same as hammer_btree_extract(cursor, HAMMER_CURSOR_GET_LEAF | HAMMER_CURSOR_GET_DATA) and it probably should have been (LEAF | DATA) instead of just DATA, according to the way hammer_get_inode(), hammer_update_inode() and hammer_update_itimes() set cursor flag. It's either LEAF or (LEAF | DATA), but not just DATA that makes sense on calling hammer_btree_extract().
sys/vfs/hammer: Add hammer_btree_extract_leaf() hammer_btree_extract() doesn't read data from block devices unless flag has HAMMER_CURSOR_GET_DATA. It doesn't really matter if the flag is HAMMER_CURSOR_GET_LEAF or not in order to just extract the node element (without reading data) as long as the flag doesn't have HAMMER_CURSOR_GET_DATA. Calling this function will cause cursor->leaf to point to the node element in question regardless of the flag value. This commit adds hammer_btree_extract_leaf() which is just a wrapper over hammer_btree_extract(cursor, HAMMER_CURSOR_GET_LEAF). This hides complexity of using HAMMER_CURSOR_GET_LEAF or 0 or anything other than HAMMER_CURSOR_GET_DATA which are all the same.
sys/vfs/hammer: Rename hammer_directory_namekey() to hammer_direntry_namekey() The name of this function should be hammer_direntry_namekey() since it's only used with directory entry rectype, but not directories as an object type. (Note that rectype for directory entry is HAMMER_RECTYPE_DIRENTRY)
sys/vfs/hammer: Rename hammer_ip_del_directory() to hammer_ip_del_direntry() The name "hammer_ip_del_directory" is confusing in the sense that it sounds like the function deletes a directory as an object type. What this function actually does is delete a directory entry which is different from a directory as an object type. (Note that rectype for directory entry is HAMMER_RECTYPE_DIRENTRY)
sys/vfs/hammer: Rename hammer_ip_add_directory() to hammer_ip_add_direntry() The name "hammer_ip_add_directory" is confusing in the sense that it sounds like the function adds a directory as an object type. What this function actually does is add a directory entry which is different from a directory as an object type. (Note that rectype for directory entry is HAMMER_RECTYPE_DIRENTRY)
sys/vfs/hammer: Use bitwise OR to generate ondisk localization Use |= to generate localization field for B-Tree elements and cursor keys instead of +=, since lower 16 bits are bitfields (or safer to treat INODE=0x1 and MISC=0x2 as bitfields). The typical code to generate ondisk localization value is to do either of the followings. ondisk_lo = local_variable + {INODE or MISC}; ondisk_lo = ip->obj_localization + {INODE or MISC}; ondisk_lo = HAMMER_XXX_LOCALIZATION + {INODE or MISC}; ^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ (A)32 bits localization (B)lower 16 bits with usually 0 for lower 16 bits for type Adding (A) and (B) to synthesize PFS id and localization type could lead to a potential bug if (A) already has type bits set to either INODE or MISC. For example if (A) had INODE for type bits and the code is to += INODE for (B), then type bits turn into MISC (1+1=2) which is not the intention of the code. This could potentially occur with the first example of above three where (A) is a local variable or a function argument. It is not too obvious from the code whether that local variable has 0 for the lower 16 bits (which basically should be). If the code just always uses |= no such thing will happen.