zfs discuss - Oct 2006 - Where is the ZFS configuration data stored?

Hi All,

Where is the ZFS configuration (zpools, mountpoints, filesystems, etc) data
stored within Solaris?  Is there something akin to vfstab or perhaps a database?

Thanks,

Steve
 
 
This message posted from opensolaris.org

On 10/12/06, Steve Goldberg <steven.goldberg at sun.com>
wrote:
> Where is the ZFS configuration (zpools, mountpoints, filesystems,
> etc) data stored within Solaris?  Is there something akin to vfstab
> or perhaps a database?

Have a look at the contents of /etc/zfs for an in-filesystem artefact
of zfs. Apart from that, the information required is stored on the
disk itself.

There is really good documentation on ZFS at the ZFS community
pages found via http://www.opensolaris.org/os/community/zfs.


cheers,
James C. McPherson
--
Solaris kernel software engineer, system admin and troubleshooter
              http://www.jmcp.homeunix.com/blog
Find me on LinkedIn @ http://www.linkedin.com/in/jamescmcpherson

James McPherson wrote:
> On 10/12/06, Steve Goldberg <steven.goldberg at sun.com> wrote:
>> Where is the ZFS configuration (zpools, mountpoints, filesystems,
>> etc) data stored within Solaris?  Is there something akin to vfstab
>> or perhaps a database?
> 
> 
> Have a look at the contents of /etc/zfs for an in-filesystem artefact
> of zfs. Apart from that, the information required is stored on the
> disk itself.
> 
> There is really good documentation on ZFS at the ZFS community
> pages found via http://www.opensolaris.org/os/community/zfs.
FYI, /etc/zfs/zpool.cache just tells us what pools to open when you boot 
up.  Everything else (mountpoints, filesystems, etc) is stored in the 
pool itself.

--matt

+ a little addition to the original quesion:

Imagine that you have a RAID attached to Solaris server. There''s ZFS on
RAID. And someday you lost your server completely (fired motherboard, physical
crash, ...). Is there any way to connect the RAID to some another server and
restore ZFS layout (not loosing all data on RAID)?
 
 
This message posted from opensolaris.org

I''ll take a crack at this.

First off, I''m assuming that the RAID you are talking about it provided
by the hardware and not by ZFS.

IF that''s the case, then it will depend on the way you created the raid
set, the bios of the controller, and whether or not these two things 
match up with any other systems.

A few of the RAID controllers I have played with has an option to 
''rebuild'' a raid set, which I get the impression (though have
never
tried) allows you to essentially tell the controller there is a raid set 
there, and if you set it up the same way as before, it will use work.

Personally, unless I was moving the disks to another system with the 
same RAID controller and BIOS, I would have no expectation it would 
work. It might, but I would not be surprised (or disappointed) if it did 
not.

If you are talking about using ZFS''s raid, then you won''t need
to do
anything. It should just work, as ZFS will be able to just import the zpool.

I hope I understood your question. (And I hope I''m telling no lies...
;)

Nathan.

Sergey wrote:
> + a little addition to the original quesion:
> 
> Imagine that you have a RAID attached to Solaris server. There''s
ZFS on RAID. And someday you lost your server completely (fired motherboard,
physical crash, ...). Is there any way to connect the RAID to some another
server and restore ZFS layout (not loosing all data on RAID)?
>  
>  
> This message posted from opensolaris.org
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

On 12/10/06, Matthew Ahrens <Matthew.Ahrens at sun.com> wrote:
> FYI, /etc/zfs/zpool.cache just tells us what pools to open when you boot
> up.  Everything else (mountpoints, filesystems, etc) is stored in the
> pool itself.
Does anyone know of any plans or strategies to remove this dependancy?

-- 
Rasputin :: Jack of All Trades - Master of Nuns
http://number9.hellooperator.net/

Dick Davies wrote:
> On 12/10/06, Matthew Ahrens <Matthew.Ahrens at sun.com> wrote:
> 
>> FYI, /etc/zfs/zpool.cache just tells us what pools to open when you
boot
>> up.  Everything else (mountpoints, filesystems, etc) is stored in the
>> pool itself.
> 
> Does anyone know of any plans or strategies to remove this dependancy?
What do you suggest in its place?


James C. McPherson
--
Solaris kernel software engineer, system admin and troubleshooter
               http://www.jmcp.homeunix.com/blog
Find me on LinkedIn @ http://www.linkedin.com/in/jamescmcpherson

James C. McPherson wrote:
> Dick Davies wrote:
>> On 12/10/06, Matthew Ahrens <Matthew.Ahrens at sun.com> wrote:
>>
>>> FYI, /etc/zfs/zpool.cache just tells us what pools to open when you
boot
>>> up.  Everything else (mountpoints, filesystems, etc) is stored in
the
>>> pool itself.
>>
>> Does anyone know of any plans or strategies to remove this dependancy?
> 
> What do you suggest in its place?
Or better yet, exactly what is the problem with having the cache ?

-- 
Darren J Moffat

James C. McPherson wrote:
> Dick Davies wrote:
>> On 12/10/06, Matthew Ahrens <Matthew.Ahrens at sun.com> wrote:
>>
>>> FYI, /etc/zfs/zpool.cache just tells us what pools to open when you
boot
>>> up.  Everything else (mountpoints, filesystems, etc) is stored in
the
>>> pool itself.
>>
>> Does anyone know of any plans or strategies to remove this dependancy?
> 
> What do you suggest in its place?
and why? what''s your objection to the current scheme?

Michael
-- 
Michael Schuster                  +49 89 46008-2974 / x62974
visit the online support center:  http://www.sun.com/osc/

Recursion, n.: see ''Recursion''

On 12/10/06, Michael Schuster <Michael.Schuster at sun.com>
wrote:
> James C. McPherson wrote:
> > Dick Davies wrote:
> >> On 12/10/06, Matthew Ahrens <Matthew.Ahrens at sun.com>
wrote:
> >>
> >>> FYI, /etc/zfs/zpool.cache just tells us what pools to open
when you boot
> >>> up.  Everything else (mountpoints, filesystems, etc) is stored
in the
> >>> pool itself.
> >>
> >> Does anyone know of any plans or strategies to remove this
dependancy?
> >
> > What do you suggest in its place?
>
> and why? what''s your objection to the current scheme?
Just the hassle of having to create a cache file in boot archives etc.


-- 
Rasputin :: Jack of All Trades - Master of Nuns
http://number9.hellooperator.net/

On Wed, Oct 11, 2006 at 11:49:48PM -0700, Matthew Ahrens
wrote:
> James McPherson wrote:
> >On 10/12/06, Steve Goldberg <steven.goldberg at sun.com> wrote:
> >>Where is the ZFS configuration (zpools, mountpoints, filesystems,
> >>etc) data stored within Solaris?  Is there something akin to vfstab
> >>or perhaps a database?
> >
> >
> >Have a look at the contents of /etc/zfs for an in-filesystem artefact
> >of zfs. Apart from that, the information required is stored on the
> >disk itself.
> >
> >There is really good documentation on ZFS at the ZFS community
> >pages found via http://www.opensolaris.org/os/community/zfs.
> 
> FYI, /etc/zfs/zpool.cache just tells us what pools to open when you boot 
> up.  Everything else (mountpoints, filesystems, etc) is stored in the 
> pool itself.
What happens if the file does not exist?  Are the devices searched for
metadata?

Ceri
-- 
That must be wonderful!  I don''t understand it at all.
                                                  -- Moliere
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20061012/0b87f299/attachment.bin>

On Thu, Oct 12, 2006 at 05:46:24PM +1000, Nathan Kroenert
wrote:
> 
> A few of the RAID controllers I have played with has an option to 
> ''rebuild'' a raid set, which I get the impression (though
have never
> tried) allows you to essentially tell the controller there is a raid set 
> there, and if you set it up the same way as before, it will use work.
Experience has taught me that if this works for you, you are problably one
of the 10 luckiest people in the world.  ;)

Especially on the PERC garbage.  Yeah, don''t even bother.  ;)

-brian

Dick Davies wrote:
> On 12/10/06, Michael Schuster <Michael.Schuster at sun.com> wrote:
>> James C. McPherson wrote:
>> > Dick Davies wrote:
>> >> On 12/10/06, Matthew Ahrens <Matthew.Ahrens at sun.com>
wrote:
>> >>
>> >>> FYI, /etc/zfs/zpool.cache just tells us what pools to open
when
>> you boot
>> >>> up.  Everything else (mountpoints, filesystems, etc) is
stored in the
>> >>> pool itself.
>> >>
>> >> Does anyone know of any plans or strategies to remove this
dependancy?
>> >
>> > What do you suggest in its place?
>>
>> and why? what''s your objection to the current scheme?
> 
> Just the hassle of having to create a cache file in boot archives etc.
Why is that a hassle ?  bootadm update-archive does that for you.

-- 
Darren J Moffat

On 12/10/06, Ceri Davies <ceri at submonkey.net>
wrote:
> On Wed, Oct 11, 2006 at 11:49:48PM -0700, Matthew Ahrens wrote:
> > FYI, /etc/zfs/zpool.cache just tells us what pools to open when you
boot
> > up.  Everything else (mountpoints, filesystems, etc) is stored in the
> > pool itself.
>
> What happens if the file does not exist?  Are the devices searched for
> metadata?
My understanding (I''ll be delighted if I''m wrong) is that you
would be stuffed.

I''d expect:

 zpool import -f

(see the manpage)
to probe /dev/dsk/ and rebuild the zpool.cache file,
but my understanding is that this a) doesn''t work yet or b) does
horrible things to your chances of surviving a reboot [0].

This means that for zfs root and failsafe boots, you need to have a
zpool.cache in your boot/miniroot archive (I probably have the terminology
wrong) otherwise the boot will fail.

I was asking if it was going to be replaced because it would really
simplify ZFS root.

Dick.

[0] going from:
  http://solaristhings.blogspot.com/2006/06/zfs-root-on-solaris-part-3.html

-- 
Rasputin :: Jack of All Trades - Master of Nuns
http://number9.hellooperator.net/

Ceri Davies wrote:
> On Wed, Oct 11, 2006 at 11:49:48PM -0700, Matthew Ahrens wrote:
> 
>>James McPherson wrote:
>>
>>>On 10/12/06, Steve Goldberg <steven.goldberg at sun.com>
wrote:
>>>
>>>>Where is the ZFS configuration (zpools, mountpoints,
filesystems,
>>>>etc) data stored within Solaris?  Is there something akin to
vfstab
>>>>or perhaps a database?
>>>
>>>
>>>Have a look at the contents of /etc/zfs for an in-filesystem
artefact
>>>of zfs. Apart from that, the information required is stored on the
>>>disk itself.
>>>
>>>There is really good documentation on ZFS at the ZFS community
>>>pages found via http://www.opensolaris.org/os/community/zfs.
>>
>>FYI, /etc/zfs/zpool.cache just tells us what pools to open when you boot
>>up.  Everything else (mountpoints, filesystems, etc) is stored in the 
>>pool itself.
> 
> 
> What happens if the file does not exist?  Are the devices searched for
> metadata?
> 
> Ceri
If the file does not exist than ZFS will not attempt to open any
pools at boot.  You must issue an explicit ''zpool import''
command to
probe the available devices for metadata to re-discover your pools.

-Mark

On Thu, Oct 12, 2006 at 02:06:15PM +0100, Dick Davies
wrote:
> On 12/10/06, Ceri Davies <ceri at submonkey.net> wrote:
> >On Wed, Oct 11, 2006 at 11:49:48PM -0700, Matthew Ahrens wrote:
> 
> >> FYI, /etc/zfs/zpool.cache just tells us what pools to open when
you boot
> >> up.  Everything else (mountpoints, filesystems, etc) is stored in
the
> >> pool itself.
> >
> >What happens if the file does not exist?  Are the devices searched for
> >metadata?
> 
> My understanding (I''ll be delighted if I''m wrong) is that
you would be
> stuffed.
> 
> I''d expect:
> 
> zpool import -f
> 
> (see the manpage)
> to probe /dev/dsk/ and rebuild the zpool.cache file,
> but my understanding is that this a) doesn''t work yet or b) does
> horrible things to your chances of surviving a reboot [0].
So how do I import a pool created on a different host for the first
time?

Ceri
-- 
That must be wonderful!  I don''t understand it at all.
                                                  -- Moliere
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20061012/3e88c275/attachment.bin>

On Thu, Oct 12, 2006 at 07:53:37AM -0600, Mark Maybee
wrote:
> Ceri Davies wrote:
> >On Wed, Oct 11, 2006 at 11:49:48PM -0700, Matthew Ahrens wrote:
> >
> >>James McPherson wrote:
> >>
> >>>On 10/12/06, Steve Goldberg <steven.goldberg at sun.com>
wrote:
> >>>
> >>>>Where is the ZFS configuration (zpools, mountpoints,
filesystems,
> >>>>etc) data stored within Solaris?  Is there something akin
to vfstab
> >>>>or perhaps a database?
> >>>
> >>>
> >>>Have a look at the contents of /etc/zfs for an in-filesystem
artefact
> >>>of zfs. Apart from that, the information required is stored on
the
> >>>disk itself.
> >>>
> >>>There is really good documentation on ZFS at the ZFS community
> >>>pages found via http://www.opensolaris.org/os/community/zfs.
> >>
> >>FYI, /etc/zfs/zpool.cache just tells us what pools to open when you
boot
> >>up.  Everything else (mountpoints, filesystems, etc) is stored in
the
> >>pool itself.
> >
> >
> >What happens if the file does not exist?  Are the devices searched for
> >metadata?
> >
> >Ceri
> 
> If the file does not exist than ZFS will not attempt to open any
> pools at boot.  You must issue an explicit ''zpool import''
command to
> probe the available devices for metadata to re-discover your pools.
OK, that''s fine then.

Ceri
-- 
That must be wonderful!  I don''t understand it at all.
                                                  -- Moliere
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20061012/86ada4f1/attachment.bin>

On Thu, Oct 12, 2006 at 02:54:05PM +0100, Ceri Davies
wrote:
> On Thu, Oct 12, 2006 at 02:06:15PM +0100, Dick Davies wrote:
> > On 12/10/06, Ceri Davies <ceri at submonkey.net> wrote:
> > >On Wed, Oct 11, 2006 at 11:49:48PM -0700, Matthew Ahrens wrote:
> > 
> > >> FYI, /etc/zfs/zpool.cache just tells us what pools to open
when you boot
> > >> up.  Everything else (mountpoints, filesystems, etc) is
stored in the
> > >> pool itself.
> > >
> > >What happens if the file does not exist?  Are the devices searched
for
> > >metadata?
> > 
> > My understanding (I''ll be delighted if I''m wrong) is
that you would be
> > stuffed.
> > 
> > I''d expect:
> > 
> > zpool import -f
> > 
> > (see the manpage)
> > to probe /dev/dsk/ and rebuild the zpool.cache file,
> > but my understanding is that this a) doesn''t work yet or b)
does
> > horrible things to your chances of surviving a reboot [0].
> 
> So how do I import a pool created on a different host for the first
> time?
Never mind, Mark just answered that.

Ceri
-- 
That must be wonderful!  I don''t understand it at all.
                                                  -- Moliere
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20061012/ad8d84f0/attachment.bin>

The configuration data is stored on the disk devices themselves, at least
primarily.

There is also a copy of the basic configuration data in the file
/etc/zfs/zpool.cache on the boot device. If this file is missing, ZFS will not
automatically import pools, but you can manually import them.

(I?m not sure how ZFS deals with the typical mirror failure case: Configure a
mirror between A and B; run for a while with B failed; reboot and B is visible
but A fails on reboot ? the goal is to avoid running on the stale mirror data,
B. I?m not sure if the zpool.cache handles this [it would have to track the
state of individual devices].)
 
 
This message posted from opensolaris.org

Ceri Davies wrote:
> On Thu, Oct 12, 2006 at 02:06:15PM +0100, Dick Davies wrote:
>> On 12/10/06, Ceri Davies <ceri at submonkey.net> wrote:
>>> On Wed, Oct 11, 2006 at 11:49:48PM -0700, Matthew Ahrens wrote:
>>>> FYI, /etc/zfs/zpool.cache just tells us what pools to open when
you boot
>>>> up.  Everything else (mountpoints, filesystems, etc) is stored
in the
>>>> pool itself.
>>> What happens if the file does not exist?  Are the devices searched
for
>>> metadata?
>> My understanding (I''ll be delighted if I''m wrong) is
that you would be
>> stuffed.
>>
>> I''d expect:
>>
>> zpool import -f
>>
>> (see the manpage)
>> to probe /dev/dsk/ and rebuild the zpool.cache file,
>> but my understanding is that this a) doesn''t work yet or b)
does
>> horrible things to your chances of surviving a reboot [0].
> 
> So how do I import a pool created on a different host for the first
> time?
zpool import [ -f ]

(provided it''s not in use *at the same time* by another host)

-- 
Michael Schuster                  +49 89 46008-2974 / x62974
visit the online support center:  http://www.sun.com/osc/

Recursion, n.: see ''Recursion''

> I was asking if it was going to be replaced because it would really
> simplify ZFS root.
> 
> Dick.
> 
> [0] going from:
>   http://solaristhings.blogspot.com/2006/06/zfs-root-on-solaris-part-3.html
I don''t know about "replaced", but presumably with the
addition of
hostid to the pool data, it could be enhanced.

For instance, VxVM has a similar file ''volboot''. 
It''s needed to import
any diskgroup that isn''t "normal" (using entire disks).  So
boot-time
imports consist of both scanning devices, looking for VxVM signatures,
then importing any with the correct hostid and flags, then attempting to
import other things explicicly mentioned in the volboot file.

Since you can put a ZFS pool in files, you''re going to have to have a
cache or something like it since you''re never going to scan them for
importable pools.

Sone one possible enhancement in ZFS could be that even if the cache
didn''t have a given (full disk) pool, it could be scanned and imported
anyway.  I don''t know if such a feature would be useful for the
implementation of ZFS root or not.  Either way it would have to wait for
the hostid stuff to go in.

-- 
Darren Dunham                                           ddunham at taos.com
Senior Technical Consultant         TAOS            http://www.taos.com/
Got some Dr Pepper?                           San Francisco, CA bay area
         < This line left intentionally blank to confuse you. >

James C. McPherson wrote:
> Dick Davies wrote:
>> On 12/10/06, Matthew Ahrens <Matthew.Ahrens at sun.com> wrote:
>>
>>> FYI, /etc/zfs/zpool.cache just tells us what pools to open when you
>>> boot
>>> up.  Everything else (mountpoints, filesystems, etc) is stored in
the
>>> pool itself.
>>
>> Does anyone know of any plans or strategies to remove this dependancy?
>
> What do you suggest in its place?
>
Directory service hooks perhaps?

Sergey wrote:
> + a little addition to the original quesion:
> 
> Imagine that you have a RAID attached to Solaris server. There''s
ZFS on RAID. And someday you lost your server completely (fired motherboard,
physical crash, ...). Is there any way to connect the RAID to some another
server and restore ZFS layout (not loosing all data on RAID)?
>  
>  

If the RAID controller is undamaged, just hook it up and go;
you can import the ZFS pool on another system seamlessly.

If the RAID controller gets damaged, you''ll need to follow
the manufacturer''s documentation to restore your data.

JBODs are simple, easy and relatively foolproof when used
w/ ZFS.

- Bart

-- 
Bart Smaalders			Solaris Kernel Performance
barts at cyber.eng.sun.com		http://blogs.sun.com/barts

Thanks Matt.  So is the config/meta info for the pool that is stored 
within the pool kept in a file?  Is the file user readable or binary? 

Steve

Matthew Ahrens wrote:
> James McPherson wrote:
>> On 10/12/06, Steve Goldberg <steven.goldberg at sun.com> wrote:
>>> Where is the ZFS configuration (zpools, mountpoints, filesystems,
>>> etc) data stored within Solaris?  Is there something akin to vfstab
>>> or perhaps a database?
>>
>>
>> Have a look at the contents of /etc/zfs for an in-filesystem artefact
>> of zfs. Apart from that, the information required is stored on the
>> disk itself.
>>
>> There is really good documentation on ZFS at the ZFS community
>> pages found via http://www.opensolaris.org/os/community/zfs.
>
> FYI, /etc/zfs/zpool.cache just tells us what pools to open when you 
> boot up.  Everything else (mountpoints, filesystems, etc) is stored in 
> the pool itself.
>
> --matt
-- 
<http://www.sun.com> 	* Steven Goldberg *
Engagement Architect

*Sun Microsystems, Inc.*
15395 SE 30th PL, Suite 120
Bellevue, WA 98011 USA
Phone +1 425 467 4349
Email Steven.Goldberg at Sun.COM

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20061012/ba869925/attachment.html>

Steven Goldberg wrote:
> Thanks Matt.  So is the config/meta info for the pool that is stored 
> within the pool kept in a file?  Is the file user readable or binary? 
It is not user-readable.  See the on-disk format document, linked here:

http://www.opensolaris.org/os/community/zfs/docs/

--matt

Bart Smaalders wrote:
> Sergey wrote:
>> + a little addition to the original quesion:
>>
>> Imagine that you have a RAID attached to Solaris server.
There''s ZFS
>> on RAID. And someday you lost your server completely (fired 
>> motherboard, physical crash, ...). Is there any way to connect the 
>> RAID to some another server and restore ZFS layout (not loosing all 
>> data on RAID)?
>>  
>>
>
>
> JBODs are simple, easy and relatively foolproof when used
> w/ ZFS. 

Yeah...but there management is lacking and you rarely see them in data 
centers. <Insert SunIT joke>.  :-P

Does it matter if the /dev names of the partitions change (i.e. from / 
dev/dsk/c2t22000050CC611005d3s0 to another machine not using sun hba  
drivers with a different/shorter name??)

thanks


keith

>
> If the file does not exist than ZFS will not attempt to open any
> pools at boot.  You must issue an explicit ''zpool import''
command to
> probe the available devices for metadata to re-discover your pools.
>

> Does it matter if the /dev names of the partitions change (i.e. from / 
> dev/dsk/c2t22000050CC611005d3s0 to another machine not using sun hba  
> drivers with a different/shorter name??)
It should not.  As long as all the disks are visible and ZFS can read
the labels, it should be able to import the pool.

-- 
Darren Dunham                                           ddunham at taos.com
Senior Technical Consultant         TAOS            http://www.taos.com/
Got some Dr Pepper?                           San Francisco, CA bay area
         < This line left intentionally blank to confuse you. >

On 12/10/06, Michael Schuster <Michael.Schuster at sun.com>
wrote:
> Ceri Davies wrote:
> > On Thu, Oct 12, 2006 at 02:06:15PM +0100, Dick Davies wrote:
> >> I''d expect:
> >>
> >> zpool import -f
> >>
> >> (see the manpage)
> >> to probe /dev/dsk/ and rebuild the zpool.cache file,
> >> but my understanding is that this a) doesn''t work yet or
b) does
> >> horrible things to your chances of surviving a reboot [0].
> > So how do I import a pool created on a different host for the first
> > time?
> zpool import [ -f ]
>
> (provided it''s not in use *at the same time* by another host)
So the warnings I''ve heard no longer apply?
If so, that''s great. Thanks for all replies.

-- 
Rasputin :: Jack of All Trades - Master of Nuns
http://number9.hellooperator.net/

> > > So how do I import a pool created on a different host for the
first
> > > time?
> 
> > zpool import [ -f ]
> >
> > (provided it''s not in use *at the same time* by another host)
> 
> So the warnings I''ve heard no longer apply?
> If so, that''s great. Thanks for all replies.
Umm, which warnings?  The "don''t import a pool on two hosts at
once"
definitely still applies.

-- 
Darren Dunham                                           ddunham at taos.com
Senior Technical Consultant         TAOS            http://www.taos.com/
Got some Dr Pepper?                           San Francisco, CA bay area
         < This line left intentionally blank to confuse you. >

On 14/10/06, Darren Dunham <ddunham at taos.com> wrote:

> > So the warnings I''ve heard no longer apply?
> > If so, that''s great. Thanks for all replies.
> Umm, which warnings?  The "don''t import a pool on two hosts
at once"
> definitely still applies.
Sure :)

I meant the reason I''d heard
( at http://solaristhings.blogspot.com/2006/06/zfs-root-on-solaris-part-3.html )
 for adding zpool.cache to your failsafe miniroot, since a ''zpool
import -f'' on
a ''root pool'' meant the box wouldn''t reboot cleanly.

-- 
Rasputin :: Jack of All Trades - Master of Nuns
http://number9.hellooperator.net/