Bug 181917 - GELI: gshsec(8) doesn't autodetect or respect written metadata; has room for improvement on usage
Summary: GELI: gshsec(8) doesn't autodetect or respect written metadata; has room for ...
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: misc (show other bugs)
Version: Unspecified
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-geom (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-09-07 21:30 UTC by Charlie
Modified: 2020-10-28 05:20 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Charlie 2013-09-07 21:30:00 UTC
A "gshsec label" command writes metadata to two providers (confirmed by a gshsec dump right after), but there's no particular command to ask the kernel to try to look for providers which are a part of a gshsec set.  So /dev/shsec/entry isn't populated automatically at times, although right after the "gshsec label" command it existed and works fine.  But also because "gshsec label" seems destructive I would prefer that it would check for existing GEOM labels of any kind, requiring a "-f" to force overwrite.  I had used it again thinking that it would detect a presence of an existing gshsec set and that the label command would trigger its appearance in /dev/shsec/.

I'd like to see gshsec and others check for the presence of existing GEOM metadata, even of the same time, and to require -f to overwrite that.

Also I'd like autodetection of a GEOM setup such as gshsec to be more comprehensive, or I'd like the user to specifically be able to manually request that this GEOM set be enabled (either through a gshsec command or some global GEOM command).

Fix: 

None
How-To-Repeat: Use gshsec label, stop and disconnect and remove one of the providers (suppose it is a .eli and one does geli detach).  Notice how that upon reattach the gshsec label isn't automatically populated.

Similarly note that there seems to be no way to resume an existing gshsec, even though there is actual metadata stored!

Note that gshsec label will happily overwrite with a new label even if there is already existing data.
Comment 1 Eitan Adler freebsd_committer freebsd_triage 2017-12-31 08:00:10 UTC
For bugs matching the following criteria:

Status: In Progress Changed: (is less than) 2014-06-01

Reset to default assignee and clear in-progress tags.

Mail being skipped