At this point, both clientA and clientB have the same pool imported and both can write to it - however, ZFS is not designed
to have multiple writers (yet), so both clients will quickly corrupt the pool as both have a different view of the pool's state.

Now that we store the hostid in the label and verify the system importing the pool was the last one that accessed the pool, the
poor man's cluster corruption scenario mentioned above can no longer happen. Below is an example using shared storage over iSCSI.
In the example, clientA is 'fsh-weakfish', clientB is 'fsh-mullet'.

First, let's create the pool on clientA (assume both clients are already setup for iSCSI):

fsh-mullet# zpool import
pool: i
id: 8574825092618243264
state: ONLINE
status: The pool was last accessed by another system.
action: The pool can be imported using its name or numeric identifier and
the '-f' flag.
see: http://www.sun.com/msg/ZFS-8000-EY
config:
i ONLINE
c2t01000003BAAAE84F00002A0045F86E49d0 ONLINE
fsh-mullet# zpool import i
cannot import 'i': pool may be in use from other system, it was last accessed by
fsh-weakfish (hostid: 0x4ab08c2) on Tue Apr 10 09:33:07 2007
use '-f' to import anyway
fsh-mullet#

Ok, we don't want to forcibly import the pool until clientA is down. So after clientA (fsh-weakfish) has rebooted,
forcibly import the pool on clientB (fsh-mullet):

One detail i'd like to point out is that you have to be careful on \*when\* you forcibly import a pool. For instance,
if you forcibly import the pool on clientB \*before\* you reboot clientA then corruption can still happen. This is because
the command reboot(1M) cleanly takes down the machine, which means it unmounts all filesystems, and unmounting a
filesystem will write a bit of data to the pool.

That's pretty f-ing cool. Nice work. Sometimes I have to forcibly do a pool import when I do a live upgrade... will that still be the case here, or does the hostid/hostname checking notice that case and eliminate the need for it?

eric, you blog is cool... but the blue on white theme is looking a little tired... how about sprucing things up a bit? also the font comes out really itty bitty teeny tiny for me. maybe try one of the newer themes built into roller?

Love, the blog fashionista.

Posted by
What not to wear on your blog
on April 10, 2007 at 07:00 AM PDT
#

It should be possible to add the hostname to 'zpool import' (without specifiying a specific pool). I decided against it as it seemed to clutter up the output and was inconsistent with regards to how specific the other 'zpool import' errors existed.

You can get that information by trying to import the specific pool. If this isn't sufficient, let me know and i can see about adding it.

With regards to having to or not having to use the '-f' flag, yep, we've made it easier on you. If you were the last one to access the pool, then '-f' is no longer needed. Try destroying a pool and importing it via 'zpool import -D <pool>' - no more '-f'!

This is an excellent change, and hopefully the "zfs mount -a" in lib/svcs/fs-local will no longer fail the service when an unimportable pool is discovered.
As an aside, this is an issue as much for a "rich man's SAN" as a "poor man's cluster"...it's expected that systems can coexist peacefully without extensive lun masking, and this will definitely help that.