Date: Sat, 12 Dec 2015 21:10:15 +0300 From: "Andrey V. Elsukov" <ae@FreeBSD.org> To: Ian Lepore <ian@freebsd.org>, Alexey Dokuchaev <danfe@FreeBSD.org> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r292058 - head/sbin/geom/class/part Message-ID: <566C6307.70200@FreeBSD.org> In-Reply-To: <1449940829.1358.154.camel@freebsd.org> References: <201512101037.tBAAbDMq065138@repo.freebsd.org> <1449767147.1358.62.camel@freebsd.org> <5669B969.5020605@FreeBSD.org> <20151212121209.GA60800@FreeBSD.org> <1449940829.1358.154.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --SqfIPepbUVEapbF5QW8uJT8oehujB4ubj Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 12.12.15 20:20, Ian Lepore wrote: > I spent much of the last week fighting with "geom destroy" and trying > to prevent the ressurection of old geoms during the creation of new > ones. It's a Big Mess and it doesn't really work well at all. I came > to the conclusion that it's not geom destroy that needs a force flag so= > much as geom create, where it would mean "it is okay to replace any > existing geom with the new one." Let's be honest. This problem is completely unrelated to what I committed= =2E > For example if you have a freebsd slice da0s1 that contains freebsd > partitions within it, and you geom destroy -F da0 then that slice and > the partitions within it disappear. Then as soon as you create a new > geom for the device and add a slice that happens to fall on the same > sector that da0s1 used to live at, suddenly that whole geom tree comes > back to life and your next command to create a new geom da0s1 fails > because it already exists. >=20 > With a task like formatting and populating an sd card with a script, > you have to deal with whatever data is on the sd card when it's first > inserted. You don't know where existing geoms might be, and it's quite= > burdensome to write script code to figure that out and do a recursive > destroy -F. (Actually, a "geom destroy -R -F" to recursively clean > everything would be quite nice.) Recursive destroying can be easily implemented in the mentioned script. But yes, this also can be done in gpart(8). > I eventually worked around the problem by using the no-commit feature > to do all the work in the sort of virtual space that creates, then > commit everything after the whole volume is laid out. That process is > another Big Mess, because it turns out you have to commit each geom > individually. >=20 > Just committing the top level doesn't recurse and that creates insanity= > because now you've got uncommitted nested geoms that are somehow locked= > such that anything you try to do results in permission errors with no > clue why root doesn't have permission to do commands that usually work > fine. (I literally had to add printfs to sys/geom code and reboot with= > that kernel to figure out what was wrong.) >=20 > Maybe it shouldn't be possible to commit an outer geom if it contains > uncommitted nested geoms. Or maybe commit should have a -R flag to > recurse automatically as well (but that would have to be implemented on= > the kernel side, unless there's some way to query from userland about > whether a geom is committed or not). You can determine what geom is uncommitted by "modified: true" attribute.= # gpart list | grep modified --=20 WBR, Andrey V. Elsukov --SqfIPepbUVEapbF5QW8uJT8oehujB4ubj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJWbGMIAAoJEAHF6gQQyKF6iwwH/1yJrnlENJPUcFRiQ4sIBSq8 ckdiSpYapakG7R3j3woeclLnYsvPrJOvve0BI6kTRlFiYF4KXP8afpE8b3Ot+pY8 1a0gb1skp8ZOcCrVPtjcep8x0mrP/lI18q6PpRmjorQnlIcAzHG0Gc87HLfg9H77 tOnapcvKYLeJPvbDWitPu85D9YuuzOBZcWG0dJ+5wwg+LVYAt5Yqkt0zo2+/0Ag9 XOWJkAJvu6jMf/8Q1/1sM8sGAN6u69jy/t63gGjyqDQ3R1CXeUMX59SMAoUB+RZd XKytQr8E1hANw4N9RClnGNi7xKbLKPIYRk7lHiAw33kvKA5QM9omOSGutWdJuZU= =GsMl -----END PGP SIGNATURE----- --SqfIPepbUVEapbF5QW8uJT8oehujB4ubj--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?566C6307.70200>