On September 13, 2006 9:32:50 AM -0700 Eric Schrock <[EMAIL PROTECTED]>
wrote:
On Wed, Sep 13, 2006 at 09:14:36AM -0700, Frank Cusack wrote:
Why again shouldn't zfs have a hostid written into the pool, to prevent
import if the hostid doesn't match?
See:
6282725 hostname/hostid should be stored in the label
Keep in mind that this is not a complete clustering solution - only a
mechanism to prevent administrator misconfiguration. In particular, it's
possible for one host to be doing a failover, and the other host open
the pool before the hostid has been written to the disk.
And why should failover be limited to SC? Why shouldn't VCS be able to
play? Why should SC have secrets on how to do failover? After all,
this is OPENsolaris. And anyway many homegrown solutions (the kind
I'm familiar with anyway) are of high quality compared to commercial
ones.
I'm not sure I understand this. There is no built-in clustering support
for UFS - simultaneously mounting the same UFS filesystem on different
hosts will corrupt your data as well. You need some sort of higher
level logic to correctly implement clustering. This is not a "SC
secret" - it's how you manage non-clustered filesystems in a failover
situation.
But UFS filesystems don't automatically get mounted (well, we know how
to not automatically mount them in /etc/vfstab). The SC "secret" is
in how importing of pools is prevented at boot time. Of course you need
more than that, but my complaint was against the idea that you cannot
build a reliable solution yourself, instead of just sharing info about
zpool.cache albeit with a warning.
Storing the hostid as a last-ditch check for administrative error is a
reasonable RFE - just one that we haven't yet gotten around to.
Claiming that it will solve the clustering problem oversimplifies the
problem and will lead to people who think they have a 'safe' homegrown
failover when in reality the right sequence of actions will irrevocably
corrupt their data.
Thanks for that clarification, very important info.
-frank
_______________________________________________
zfs-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
