Issue #2852 has been updated by abale.
/boot/loader.conf I actually added: vfs.hammer.skip_redo=2 Note that it felt like all version of DragonFlyBSD tested ignored this tuner flag. ---------------------------------------- Bug #2852: Hammer File System - hangs on undo during system boot / mount - will not recover on DragonFlyBSD newer than 3.6.0 http://bugs.dragonflybsd.org/issues/2852#change-12734 * Author: abale * Status: New * Priority: Normal * Assignee: * Category: VFS subsystem * Target version: 4.2.x ---------------------------------------- Short Description: In DragonFlyBSD version 4.2.4 - Hammer file system would not recover on boot undo process - just hangs. Installed DragonFlyBSD version 3.6.0 - Recovery continued and succeeded. Long Description: The HAMMER file system on my storage server failed today upon forced reboot. System went the expected route on boot, and attempted a recovery of the file system. However, it was unable to continue - it would just hang at the undo. System environment is running on KVM (Proxmox distribution) with a directly attached SATA drive holding the HAMMER volume for storage. This volume is then shared over NFS for use via the Proxmox server to host additional VMs. The DragonFlyBSD 4.2.4 system hung during a VM deletion, and I forced a reboot in the Virtual Environment. HAMMER shutdown was dirty, forcing an expected undo operation to bring the drive consistent. UNDO operation would run for about 5 seconds (disk light), then DragonFlyBSD would just hang. I disconnected the drive to allow the DFLY 4.2.4 to boot, and change the mount flags in FSTAB to prevent the auto-mount. I rebooted, attempted a manual mount_hammer - same result I then added the tunable to /boot/loader.conf: vfs.hammer.skip_undo=1 - rebooted, same result on mount. Changed to vfs.hammer.skip_undo=2 - rebooted, same result on mount. I downloaded and setup DFLY_Latest (11/22), and ran the same sequence - same issue. This was followed with: - DFLY 3.8.2 - DFLY 3.6.0 Running the mount_hammer on 3.6.0 (no skip_undo) resulted in the undo processing continuing and completing, recovery the HAMMER volume intact. At this point, I shutdown the VM, disconnected the drive from DFLY-3.8.2 and reconnected it to the DFLY-4.2.4 VM. The VM booted successfully and mounted the HAMMER volume. This appears to suggest there is a bug in the HAMMER recovery code in versions of DFLY above 3.6.0. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account
