[Bug 242883] geom: GPT inside gconcat loads incorrectly

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242883

            Bug ID: 242883
           Summary: geom: GPT inside gconcat loads incorrectly
           Product: Base System
           Version: CURRENT
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: kern
          Assignee: bugs at FreeBSD.org
          Reporter: noah.bergbauer at tum.de

Example:

# truncate -s 1G test.bin
# mdconfig -f test.bin
md0
# gconcat label outer md0
# gpart create -s gpt concat/outer
concat/outer created
# gpart add -t freebsd concat/outer
concat/outers1 added
# gconcat label inner concat/outers1
# mdconfig -du 0

At this point test.bin contains a gconcat "inner" inside a GPT gpart inside a
gconcat "outer".

However:

# mdconfig -f test.bin
md0
# geom -t
Geom                                    Class      Provider
md0                                     MD         md0
  md0                                   DEV
  md0                                   PART       md0s1
    md0s1                               DEV
    inner                               CONCAT     concat/inner
      concat/inner                      DEV
  outer                                 CONCAT     concat/outer
    concat/outer                        DEV
    concat/outer                        PART       concat/outers1
      concat/outers1                    DEV

In the words of dmesg:

GEOM_CONCAT: Device outer created (id=1505886249).
GEOM_CONCAT: Disk md0 attached to outer.
GEOM_CONCAT: Device concat/outer activated.
GEOM: md0: the secondary GPT header is not in the last LBA.
GEOM_CONCAT: Device inner created (id=4175896209).
GEOM_CONCAT: Disk md0s1 attached to inner.
GEOM_CONCAT: Device concat/inner activated.
GEOM_CONCAT: Cannot add disk concat/outers1 to inner (error=17).

The kernel sees two perspectives of our GPT table: The correct one from inside
of concat/outer and the incorrect one on raw md0 where the last sector (which
contains the gconcat info) is simply considered broken (hence the warning).

This behavior is arguably correct - a command like `mount /dev/concat/outers1
/mnt` would work correctly. However we run into problems when stacking other
geoms on top of the gpart, like concat/inner in this example. The kernel
actually notices the (incorrectly accessed) md0s1 FIRST, creates the gconcat
provider on top of that and then REJECTS the (correct) concat/outers1.

This, in spite of being wrong, still works for reading. But the read lock on
md0 through the wrong access paths prevents us from modifying the GPT in
concat/outer. The only workaround is to manually stop all inner geoms on
md0(raw) and try to somehow make it re-taste correctly. Obviously this has to
be done on every reboot and requires all filesystems inside this construction
to be temporarily unmounted.

Not sure what the correct solution is. Either gconcat needs to somehow
understand that concat/outers1 is a "better" path than md0s1 and replace the
underlying access path. Or the kernel must somehow ensure that the
non-corrupted path is always seen first, leaving the perspective with the
corrupted gpt only as a very last resort.

-- 
You are receiving this mail because:
You are the assignee for the bug.