sys/vfs/hammer2: Minor cleanup - blockref size was 64 bytes back in 2012, but 128 bytes now. - Doesn't make much sense to assert vap in here, as it's already dereferenced earlier in this same function. - "hammer2_tid_t lhcbase" should be "hammer2_key_t lhcbase", though both are uint64_t.
sys/vfs/hammer2: Remove unused lbase local variables for hammer2_calc_logical() These variables are never used after assigned values. If the third argument is NULL, the second argument is unused either, in which case 0 is usually passed. If the fourth argument is NULL, the first argument is unused either, in which case NULL can be passed. (So if at least the last 2 arguments are NULL, caller is just looking for an fs block size, which is always 64KB...)
Revert "sys/vfs/hammer2: Avoid void* pointer arithmetic" This reverts commit 3f53c53686fc9e236fb9949c8d2a665ce27832be. Unlike makefs' buf::b_data in DragonFly (until 02f727fe249ae3252e4721f806f49ded0544938e), the kernel buf::b_data in DragonFly has always been of caddr_t, so explicit cast was never needed.
sys/vfs/hammer2: Fix -Wpointer-sign warnings Warned on Linux user space. The name pointer points to namecache name which is of char*. vnops passes name pointer to hammer2_dirent_create() which takes char*. warning: pointer targets in passing argument 2 of 'hammer2_dirent_create' differ in signedness [-Wpointer-sign]
sys/vfs/hammer2: Fix many comments * "lru_spin; /* inumber lookup */" -> lru_spin isn't for inode. * "If an error occurred we eat the lock" -> "eat the lock" was removed in c603b86b77206805493fc181d3576ecd1786e056 in 2015. The rest of the comment (not removed) seems obsolete too. * "removed from the parent's btree" -> Typo for rbtree. * "pointing it to an embedded data structure and copying the data from the buffer" -> No longer implemented like this since 01eabad4d93a8dc8f0f01a6209b384b1e010bb8c in 2012. * "Called to clean up cached DIOs on umount" -> This isn't specific to unmount, called regularly if iofree_count > dio_limit. * "voldata is not yet loaded" -> It's already loaded. * "so do not pass cluster", etc -> "cluster" no longer appears here since b7add6753e221920947c96fab3314c39a2f67fe4 in 2015. * "multiple hammer2_inode structures can be aliased to the same chain element, for example for hardlinks" -> This comment from 2013 seems to only apply to hardlink mechanism back then, which was something completely different.
hammer2 - Fix issue where deleted files sometimes linger until umount (2) This is related to the issue of having to retain the inodes for deleted files that still have live references. Even though their nlinks has dropped to 0, such inodes must be retained and be fully operational until the last live reference goes away. When that reference DOES go away, we need to dispose of the inode as quickly as possible. * The last fix wasn't good enough. Some vnodes still linger for indefinite periods of time after a rm -rf. In addition, the last fix attempted to clean-out inodes that might have still had dirty buffers associated with the vnode. * Fall-back to the method that UFS and HAMMER1 use, which is to obtain a full ref on ip->vp using vget() (or similar) that we can cycle to force the vnode to be inactivated. This also entails using the inode lock in the inactive/reclaim path to interlock the ip->vp accesss, unfortunately. The vnode buffers and inode are now cleaned up in the inactivation path (when nlinks is 0) instead of the reclaim path. * Validated against a (roughly) 20 million inode distfile unpack and another few million inodes created via grok processing. * Add a vfs support function in the kernel called vfinalize() which operates on a referenced vnode. This function flags the vnode for immediate deactivation when the last ref is released.
hammer2 - Fix issue where deleted files sometimes linger until umount * Hammer2 was using a namecache heuristic to determine if a file being deleted was still open or not, but had not coded any sort of fall-back if the heuristic failed. This created an issue where the inodes for deleted files would sometimes linger until the filesystem is unmounted (typically at system shutdown). If the system were to crash, these inodes would remain in the media topology forever. This case primarily occurs when a large number of files are being deleted. * Replace the heuristic with a proper interlock so H2 knows with certainty whether a file being removed still has system refs on it or not.