On 9/13/06, Eric Schrock <[EMAIL PROTECTED]> wrote:
On Wed, Sep 13, 2006 at 02:29:55PM -0500, James Dickens wrote:
>
> this would not be the first time that Solaris overrided an administive
> command, because its just not safe or sane to do so. For example.
>
> rm -rf /
As I've repeated before, and will continue to repeat, it's not actually
possible for ZFS to determine whether a pool is in active use (short of
making ZFS a cluster-aware filesystem). Adding arbitrary delays doesn't
change this fact, and only less likely. I've given you examples of
where this behavior is safe and sane and useful, so the above
simplification (upon which most of the other arguments are based) isn't
really valid.
I disagree with this, isn't there way to track when the last read was?
Even computing the last write access time that you are already
recommending, then sleeping for 30 seconds and recompute the value by
accessing the disk again and compare,even a read on the pool will
possibly cause a write if ATIME tracking is enabled on the filesystem,
if someone is accessing the pool we are importing underneath us, it is
a dead give away that we are about to explode if we continue on this
path.
I'm curious why you didn't comment on my other suggestion (displaying
last accessed host and time as part of 'zpool import'), which seems to
solve your problem by giving the administrator the data they need to
make an appropriate decision.
its a good suggestion, it just doesn't go far enough in my opinion.
As Anton and other have mentioned in previous discussions there seems to
be several clear RFEs that everyone can agree with:
1. Store the hostid, hostname, and last time written as part of the
label.
2. During auto-import (aka open), if the the hostid is different from
our own, fault the pool and generate an appropriate FMA event.
3. During manual import, display the last hostname and time accessed if
the hostid is not our own, and the pool is still marked ACTIVE.
This prevents administrators from shooting themselves in the foot, while
still allowing explicit cluster failover to operate with more
information than was available before.
if this is what the community decides I can live with this, I may even
provide a patch for OpenSolaris distros that does the more intensive
check, it seems to be an easy fix once you have complete #1.
James
- Eric
--
Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
