svn commit: r292058 - head/sbin/geom/class/part

[Andrey V. Elsukov]

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.

> 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.
> 
> 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.
> 
> 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.)
> 
> 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

-- 
WBR, Andrey V. Elsukov

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 538 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/svn-src-head/attachments/20151212/7a95d044/attachment.sig>