Wow! I solved a tricky problem this morning thanks to Zones & ZFS integration. We have a SAS SPDS database environment running on Sol10 06/06. The SPDS database is unique in that when a table is being updated by one user it is unavailable to the rest of the user community. Our nightly update jobs (occassionally they turn into day jobs when they take longer :-() were coming in the way of our normal usage. So I put on my ZFS cap and figure it can be simply solved by deploying the ''clone'' feature. Simply stated I''d create a clone of all the SPDS filesystems and start another instance of SPDS to read/write from the cloned data. Unfortunately I hit a wall when I realized that there is no way to update the SPDS metadata (binary file containing a description of the physical structure of the database) with the new directory path. I was stumped until it occurred to me that I can solve it by simply marrying the clones with a Solaris Zone!!!! Now our problem is solved as follows: 1. Stop local zone 2. Reclaim the ZFS clones in the global-zone 3. Destroy the clone/snapshot 4. Recreate the clone/snapshot 5. Restart the local zone 6. Start SPDS in the local zone and it works beautifully because it sees all the files it needs per its metadata!!! To accomplish the same in traditional methods would have required a SAN disk, disk merge/split, ... You get the picture, ugly! Chalk one more victory for the Solaris 10 Zones/ZFS!!! Thanks to the developers of these features that enabled me elegantly solve a difficult problem. -Anantha- This message posted from opensolaris.org
I''ve found a small bug in the ZFS & Zones integration in Sol10 06/06 release. This evening I started tweaking my configuration to make it consistent (I like orthogonal naming standards) and hit upon this situation: - Setup a ZFS clone as /zfspool/bluenile/cloneapps; this is a clone of my global zones'' /apps filesystem. - Updated my zone configuration for bluenile to use the /zfspool/bluenile/cloneapps - Booted my zone and I couldn''t see the just provisioned ZFS filesystem!!!! Upon a hunch I recreated the ZFS clone but this time I named it as /zfspool/bluenile/capps to reduce the overall length and updated my Zone config. Upon boot I was able to see the ZFS filesystem! I''m not sure if this is a ZFS, Zones, or ZFS/Zones integration problem. It is not a show stopper but in the spirit of ZFS being ''unlimited'' in all dimensions why are we limiting the length of the clone name? This message posted from opensolaris.org
Some people have privately asked me the configuration details when the problem
was encountered. Here they are:
zonecfg:bluenile> info
zonepath: /zones/bluenile
autoboot: false
pool:
inherit-pkg-dir:
dir: /lib
inherit-pkg-dir:
dir: /platform
inherit-pkg-dir:
dir: /sbin
inherit-pkg-dir:
dir: /usr
net:
address: a.b.c.d
physical: ce0
dataset:
name: mtdc/bluenile/cloneu001
dataset:
name: mtdc/bluenile/cloneu002
dataset:
name: mtdc/bluenile/cloneu003
dataset:
name: mtdc/bluenile/cloneu004
dataset:
name: mtdc/bluenile/cloneu005
dataset:
name: mtdc/bluenile/cloneu006
dataset:
name: mtdc/bluenile/cloneu007
dataset:
name: mtdc/bluenile/cloneu008
dataset:
name: mtdc/bluenile/cloneu099
dataset:
name: zfspool/bluenile/capps [b]<-- This is the dataset in question;
if you replace ''capps'' with ''cloneapps''
local zone stops seeing it.[/b]
dataset:
name: zfspool/bluenile/home
This message posted from opensolaris.org