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
signature.asc
Description: OpenPGP digital signature