DragonFly master change about s0 (compatibility slice)

[Autumn Jolitz]

Thanks!

I’m now running on 6.5-DEVELOPMENT 51591aff67978c86de99839e31d8c8fcc54bc316.

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 VFS_FRUIT enabled, copy the resultant /usr/obj/dports/$(cd /usr/dports ; echo net/samba4*)/pkg/*.pkg into /usr/dports/package,  pkg repo /usr/dports/package && pkg update -r local && pkg install -r local "$(cd /usr/dports ; echo net/samba4*)". 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.

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. 

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. xdisk 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 hammer2 info /dev/serno/.vbd (aka /dev/xa9s1d) and see the hammer2 status of a volume inside a virtual machine.

Autumn



> On Mar 5, 2026, at 4:42 AM, Aaron LI <aly at aaronly.me> wrote:
> 
> On 3/3/26 2:27 PM, Aaron LI wrote:
>> On 3/3/26 1:49 PM, Aaron LI wrote:
>>> On 3/3/26 11:32 AM, Autumn Jolitz wrote:
>>>> 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.
>>> 
>>> 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.
>>> 
>>> So one must format a disk with either MBR or GPT before using.
>>> 
>>> For MBR-formatted disks, slices start from 1 (i.e., s1, s2, s3, s4).
>>> For GPT-formatted disks, slices start from 0 (e.g., s0, s1, ...).
>>> 
>>> [1] kernel: Don't siliently ignore EINVAL from mbrinit() and gptinit()
>>> 
>>> https://gitweb.dragonflybsd.org/dragonfly.git/ commitdiff/8cf8601ebae6a54f01fe9a7aed045832fc6a903b
>>> [2] kernel: Add DSO_NOMBR flag to allow VN(4) disks to have no MBR
>>> 
>>> https://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/ f687b277b90809ae7df59f012ba2c7312b608545
>>> 
>>>> Context:
>>>> 
>>>> - I have four 8TB SATA drives mounted using hammer pls-mirror-stream between each pair
>>>> - 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)
>>>>     - Example MBR drive: /dev/serno/WWZAEENJ [1]
>>> 
>>> With the updated master, kernel will not automatically create the s0 compatibility slice for an unformatted disk (i.e., no MBR or GPT).
>>> 
>>> 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.
>>> 
>>>> - one of them has a GPT layout (via `gpt create`/`gpt add -i 0 -t hammer`)
>>>>     - Example GPT drive: /dev/serno/WWZABTRY [2]
>>>> 
>>>> 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)
>>>> 
>>>> By comparison, an install-all of DragonFly_RELEASE_6_4 shows and mounts both MBR and GPT drives successfully.
>>>> 
>>>> In any case, I’m going to migrate my mirrors to GPT partition headers, but this is a real bug that others could encounter.
>> Hi Autumn,
>> 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.
>> I'll recheck the code to restore the s0 compatibility slice support later.
> 
> The s0 compatibility slice support has just been restored in commit
> b73d6e474c7b35d6ee6626f0443020ad40e2ebc6.
> 
> By the way, I amended the kernel message to be more intuitive:
> 
> <disk>: MBR magic not found; assume a COMPATIBILITY_SLICE (s0)
> 
> 
> Cheers,
> Aaron

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dragonflybsd.org/pipermail/users/attachments/20260311/a0d8b53e/attachment.htm>