DragonFly master change about s0 (compatibility slice)

[Aaron LI]

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