A disk died, so I migrated to SSDs. Figuring now was a good time, I revisited HAMMER2 clustering.
HAMMER2 is still in development, and DragonflyBSD 6.4 (which was the version used in the last post about this) is still the latest release. There's likely work done that'll go into 6.5, but I don't particularly want to host my files on top of moving code. The upper-limit of what I've found works without issue can be found below.
Not particularly related to HAMMER2, but I'll cover it so you can see the entire process of setting up a disk for storage:
# Wipe the front of the disk [dfly] [0] ~/ # dd if=/dev/zero of=/dev/da8 count=1024 bs=1m # Destroy a GPT if there's one kicking about [dfly] [0] ~/ # gpt destroy da8 # Create a new GPT [dfly] [0] ~/ # gpt create -f da8 # Add a dragonfly slice covering the entire disk [dfly] [0] ~/ # gpt add -t dfly da8
Disklabels aren't something you'll see on GNU+Linux. At this point, most (if not all) of the work prior to creating a new filesystem has been adopted by fdisk, parted and similar tools.
# Create a disklabel on the slice [dfly] [0] ~/ # disklabel64 -r -w /dev/da8s0 # Modify the disklabel to create a 'h' partition covering the entire slice [dfly] [0] ~/ # disklabel64 -e /dev/da8s0 ... h: * * HAMMER2
# Create a new HAMMER2 filesystem with only a 'LOCAL' PFS.
[dfly] [0] ~/ # newfs_hammer2 -L none /dev/da8s0h
# Mount all PFS with the LOCAL tag
[dfly] [0] ~/ # hammer2 mountall
# List the mountpoints for those LOCAL PFS'
[dfly] [0] ~/ # hammer2 info
...
/dev/serno/S76ZNJ0WB06520E.s0h:
Type ClusterId (pfs_clid) Label
MASTER e666479a-a19f-11ee-918c-b1416f0c36cc LOCAL
...
# Create a new PFS for data on that filesystem with the name 'H2C'
[dfly] [0] ~/ # hammer2 -s /dev/serno/S76ZNJ0WB06520E.s0h -t MASTER pfs-create H2C
# Mount our new H2C PFS by tag.
[dfly] [0] ~/ # mount @H2C /mnt/H2C
Where I specified -L none to instruct newfs_hammer2 to only create a 'LOCAL' PFS, I could have instead ran -L H2C. This would produce an identical result, without the need to create the H2C as an individual step. However newfs_hammer2 does not allow specifying a PFS type other than (implicit) MASTER."
hammer2(8) lists a number of different types of PFS' that can be created with the -t flag. Unfortunately, while the documentation is (strictly speaking) correct - at the moment all types other than MASTER, and perhaps DUMMY, seem to be in rather dangerous states. The kernel panics I'd attributed to the 2-bay USB enclosure happen even with two individually connected disks. Attempting to create a SLAVE, SOFT_SLAVE or SOFT_MASTER PFS led to panics, forcing a reboot. Somehow I missed this bug report last time I attempted this. Hopefully there's some guards added to the command in the future.
It's a little disappointing, given PFS mirroring worked for me for quite a long time with HAMMER1. But it isn't a particularly big issue to instead run a periodic rsync.
Tapes! LTO-5 tape drive and tapes on the way. Though this'll be happening in some sort of GNU+Linux, not DragonflyBSD, as the tools for reading drive and media metadata don't seem to be available.