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=3D242883 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=3D1505886249). 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=3D4175896209). GEOM_CONCAT: Disk md0s1 attached to inner. GEOM_CONCAT: Device concat/inner activated. GEOM_CONCAT: Cannot add disk concat/outers1 to inner (error=3D17). The kernel sees two perspectives of our GPT table: The correct one from ins= ide of concat/outer and the incorrect one on raw md0 where the last sector (whi= ch contains the gconcat info) is simply considered broken (hence the warning). This behavior is arguably correct - a command like `mount /dev/concat/outer= s1 /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 constructi= on 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. --=20 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>