DragonFly master change about s0 (compatibility slice)

[Aaron LI]

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.

Thank you for the detailed report.

Cheers,
Aaron