DragonFly master change about s0 (compatibility slice)

[Aaron LI]

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.

It's a slight behavior change as explained above.
> [1] Example of MBR fdisk drive:
> 
>      nyx:~$ fdisk /dev/serno/WWZAEENJ
>      ******* Working on device /dev/serno/WWZAEENJ *******
>      parameters extracted from device are:
>      cylinders=972801 heads=255 sectors/track=63 (16065 blks/cyl)
> 
>      Figures below won't work with BIOS for partitions not in cyl 1
>      parameters to be used for BIOS calculations are:
>      cylinders=972801 heads=255 sectors/track=63 (16065 blks/cyl)
> 
>      fdisk: invalid fdisk partition table found
>      Warning: Ending logical block > 2TB, using max value
>      Media sector size is 512
>      Warning: BIOS sector numbering starts with sector 1
>      Information from DOS bootblock is:
>      The data for partition 1 is:
>      <UNUSED>
>      The data for partition 2 is:
>      <UNUSED>
>      The data for partition 3 is:
>      <UNUSED>
>      The data for partition 4 is:
>      sysid 108,(DragonFly BSD)
>          start 63, size 4294967295 (2097151 Meg), flag 80 (active)
>          beg: cyl 0/ head 1/ sector 1;
>          end: cyl 0/ head 0/ sector 62
The information for partition 4 (i.e., s4) is in-memory only, but not 
on-disk.  The disk doesn't have MBR so all 4 partitions are <UNUSED>. 
fdisk(8) is misleading here.  I'll try to fix it later.


Cheers,
Aaron