>Number:         181917
>Category:       misc
>Synopsis:       GELI: gshsec(8) doesn't autodetect or respect written 
>metadata; has room for improvement on usage
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Sep 07 20:30:00 UTC 2013
>Closed-Date:
>Last-Modified:
>Originator:     Charlie R
>Release:        9.2/amd64
>Organization:
None
>Environment:
FreeBSD localhost 9.2-RC2 FreeBSD 9.2-RC2 #0 r254368: Thu Aug 15 18:49:04 UTC 
2013     [email protected]:/usr/obj/usr/src/sys/GENERIC  amd64
>Description:
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).
>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.
>Fix:
None

>Release-Note:
>Audit-Trail:
>Unformatted:
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "[email protected]"

Reply via email to