Date: Wed, 25 Dec 2019 15:13:51 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 242883] geom: GPT inside gconcat loads incorrectly Message-ID: <bug-242883-227@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
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@FreeBSD.org Reporter: noah.bergbauer@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-242883-227>