<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">Thanks!<div><br></div><div>I’m now running on 6.5-DEVELOPMENT 51591aff67978c86de99839e31d8c8fcc54bc316.</div><div><br></div><div>My NAS has been running on Dragonfly since 2016. It’s been very reliable as a Time Machine endpoint and SMB server. Each release, I build net/samba4* package from dports with <font face="Courier New">VFS_FRUIT</font> enabled, copy the resultant <font face="Courier New">/usr/obj/dports/$(cd /usr/dports ; echo net/samba4*)/pkg/*.pkg</font> into <font face="Courier New">/usr/dports/package</font>, <font face="Courier New">pkg repo /usr/dports/package &&</font> <font face="Courier New">pkg update -r local && pkg install -r local "$(cd /usr/dports ; echo net/samba4*)"</font>. The NAS has four hammer hard drives, two of which are mirrors of the other two. I decided that I needed to fix the “lack of actual partition map” issue for the long term. It was fairly straight forwards, like recovering from drive failure.</div><div><br></div><div>One of the things I’ve rather liked about the hammer filesystem is the ability to replicate with a delay and bandwidth limit in a transactional manner — it smooths out write load to a replica which I think is healthier for the drive overall. </div><div><br></div><div>I don’t know if I can do the same with hammer2 yet. I really like the named PFS of hammer2 — it seems more like a ZFS dataset. It also deletes nice too. <font face="Courier New">xdisk</font> fascinates me — I don’t know how to disconnect a host safely without rebooting. But I found it interesting that I could call from one machine <span style="font-family: "Courier New";">hammer2 info /dev/serno/.vbd</span> (aka /dev/xa9s1d) and see the hammer2 status of a volume inside a virtual machine.</div><div><br></div><div>Autumn</div><div><br></div><div><br></div><div><div><br><blockquote type="cite"><div>On Mar 5, 2026, at 4:42 AM, Aaron LI <aly@aaronly.me> wrote:</div><br class="Apple-interchange-newline"><div><div>On 3/3/26 2:27 PM, Aaron LI wrote:<br><blockquote type="cite">On 3/3/26 1:49 PM, Aaron LI wrote:<br><blockquote type="cite">On 3/3/26 11:32 AM, Autumn Jolitz wrote:<br><blockquote type="cite">Yep, it was what I suspected. There is a bug in the latest master (as of 2f464f7b29ef0068fcf089f37306a0fded066771) — when encountering an MBR partition map caused by calling `newfs_hammer` on a device like `/ dev/ serno/WWZAEENJ`, the kernel will not recognize the partition map and think the drives are unformatted. Release 6.4 however recognizes those drives just fine.<br></blockquote><br>Yes. I indeed made a change to the s0 (compatibility slice) support in commit 8cf8601ebae6a54f01fe9a7aed045832fc6a903b [1]. With that commit, a disk without MBR or GPT is ignored by kernel, instead of assuming there is the compatibility slice (s0) covering the whole disk. A later commit (f687b277b90809ae7df59f012ba2c7312b608545 [2]) only made a special case for vn(4) disk because that's actually used by our nrelease framework.<br><br>So one must format a disk with either MBR or GPT before using.<br><br>For MBR-formatted disks, slices start from 1 (i.e., s1, s2, s3, s4).<br>For GPT-formatted disks, slices start from 0 (e.g., s0, s1, ...).<br><br>[1] kernel: Don't siliently ignore EINVAL from mbrinit() and gptinit()<br><br>https://gitweb.dragonflybsd.org/dragonfly.git/ commitdiff/8cf8601ebae6a54f01fe9a7aed045832fc6a903b<br>[2] kernel: Add DSO_NOMBR flag to allow VN(4) disks to have no MBR<br><br>https://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/ f687b277b90809ae7df59f012ba2c7312b608545<br><br><blockquote type="cite">Context:<br><br>- I have four 8TB SATA drives mounted using hammer pls-mirror-stream between each pair<br>- three of them have an MBR created via calling `newfs_hammer /dev/ serno/WWZAEENJ` (i.e. either on the device or on .s0 of the device)<br> - Example MBR drive: /dev/serno/WWZAEENJ [1]<br></blockquote><br>With the updated master, kernel will not automatically create the s0 compatibility slice for an unformatted disk (i.e., no MBR or GPT).<br><br>By the way, I would never invoke 'newfs' on a disk (e.g., da0) rather than on a slice/partition (e.g., da0s0, da0s1), although the old behavior would make 'da0' == 'da0s0' in that case.<br><br><blockquote type="cite">- one of them has a GPT layout (via `gpt create`/`gpt add -i 0 -t hammer`)<br> - Example GPT drive: /dev/serno/WWZABTRY [2]<br><br>An install-all of master will fail to show on boot /dev/serno/ WWZAEENJ.s0 (MBR) but does show (and mount successfully!) /dev/serno/ WWZABTRY.s0 (GPT)<br><br>By comparison, an install-all of DragonFly_RELEASE_6_4 shows and mounts both MBR and GPT drives successfully.<br><br>In any case, I’m going to migrate my mirrors to GPT partition headers, but this is a real bug that others could encounter.<br></blockquote></blockquote>Hi Autumn,<br>After another think, I agree with you and the above change will indeed cause trouble for such rare users: the filesystem previously created directly on an unformatted disk would disappear and unusable on the new master kernel, and there is no empty space at the disk beginning to create a MBR for migration.<br>I'll recheck the code to restore the s0 compatibility slice support later.<br></blockquote><br>The s0 compatibility slice support has just been restored in commit<br>b73d6e474c7b35d6ee6626f0443020ad40e2ebc6.<br><br>By the way, I amended the kernel message to be more intuitive:<br><br><disk>: MBR magic not found; assume a COMPATIBILITY_SLICE (s0)<br><br><br>Cheers,<br>Aaron<br></div></div></blockquote></div><br></div></body></html>