On 04/22/10 15:35, Evan Layton wrote:
On 4/22/10 3:07 PM, Ethan Quach wrote:
On 04/21/10 09:01, Evan Layton wrote:
On 4/21/10 8:23 AM, Dave Miner wrote:
On 04/21/10 12:45 AM, Evan Layton wrote:
On 4/20/10 10:18 PM, Seth Goldberg wrote:
Quoting Evan Layton, who wrote the following on Tue, 20 Apr 2010:
On 4/20/10 10:10 PM, Seth Goldberg wrote:
Quoting Seth Goldberg, who wrote the following on Tue, 20 Apr
2010:
Well, I was just suggesting the minimum set of files needed to at
least show a boot panic :). unix, genunix and the boot archive
are
that set, I believe.
I should say that genunix will be loaded from the boot archive, so
testing the validity of genunix in the boot archive (i.e. via
loopback
mounting it and running `file' or elfdump on genunix (admittedly,
both
are not great tests, but they're something -- other suggestions
are
welcomed :))) might be a better idea.
Ick, that's really not something I really want to be doing from a C
library if I can avoid it...
I hear ya. I'm just suggesting checks that would made validation
more
airtight. Most of them are just calls to system() and checking the
return values.
I don't think we can really get to "airtight". ;-)
I'd really rather not add this kind of check that requires running
something like elfdump. It doesn't really "ensure" that genunix is
valid only that it is more likely to be valid. However that "more
likely to be valid" check may be something we should do anyway. If
folks feel that we should do this check I'll add that as well.
I think you have two possible requirements, which likely lead to
different solutions:
I agree that based on the comments and what you've put here that
these are the requirements.
- don't list datasets in "beadm list" that really aren't BE's. Any
checks here need to be cheap, as systems with a few dozen BE's are
known
to exist in the wild and having a listing take many seconds on such a
system would be disagreeable (beadm list on a system with 50 BE's
takes
.25s with the existing implementation).
This is what I was thinking when I coded the fix and this is what
the fix handles. However as you point out this really isn't enough
for the activate case.
- don't activate BE's that aren't bootable. Activation can be
reasonably
expected to take a few seconds, so more time-consuming tests are
allowable, and you're only acting on one BE. I don't think there's any
scenario in which "airtight" is possible, though; you'd be into
running
things like "pkg verify" to get very close, and even that would be
problematic in the face of developer use of (cap-I) Install for kernel
work.
I agree that activate should be treated differently and that we should
do the extra checking in this instance. I also think that this check
should have it's own error message to more clearly state that the BE
may
not be bootable. However I think that this check should only be done if
this BE passes the cheaper check so that we're not running the more
time-consuming check for a BE that we already know isn't valid.
Wait, don't you mean, "that this check should only be done if
this BE *fails* the cheaper check" ? Otherwise, it'd seem you're
considering the cheaper check failure as meaning a definitive
invalid BE. That doesn't sound right.
Why wouldn't that be right? If the BE has no uuid and doesn't have
the files that we're checking it's by definition an invalid BE.
Also I think the "cheaper" check should be done for the rest of the
subcommands to limit users attempting to act on invalid BE's without
impacting those commands as much.
But the "cheaper" check, by itself, does not tell us anything
definitive.
So why would we base any decisions on that data alone, for any of
the other subcommands?
Yes it does. If no uuid and files we're checking don't exist it's pretty
clear that this is not a valid BE.
From your last reply, I thought the cheaper check was going to
be changed to be without the files check because checking files isn't
cheap. But OK, I see what you mean now.
There is no way that we can nor do I
think we want to attempt an "airtight" check for validity. The only place
that we may want to go further with the check is when we're activating
the BE so that we're at least attempting to see if the BE is bootable.
What is the difference between this further check for bootability
and the files check?
If the BE is invalid based on this check and we then allow them to do
other actions on it then they could be very surprised when they can't
activate it or create based on it. I don't think this is a direction
we should go. If the BE is invalid it's not a listed or available to
act on.
I just wanted to make sure beadm doesn't inadvertently get
completely locked out of a BE because the validity heuristic
we're using fails.
For example, if we deemed a BE untouchable by all subcommands
because it lacked some file, the first thing the user is going to try
to do is mount the BE and fix whatever was broken.
# beadm activate foo
ERROR: foo cannot be activated because its missing a boot archive
#
# beadm mount foo /a
# bootadm update-archive -R /a
*I think* with what you're proposing, as long as foo has a uuid,
it can still be mounted, yes?
thanks,
-ethan
Or is "cheaper" check something other than uuid now?
The cheaper check was not just checking for the uuid. If the uuid existed
then we know we created the BE so we expect it to be OK. If however there
is no uuid then we need to check further. It's at this point that we
check
for the existence of the files described in this thread. If those don't
exist then this is definitely not a valid BE.
-ethan
-evan
-ethan
Thanks!
-evan
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
