zfs discuss - Apr 2006 - RE: Shrinking a zpool / BCV consistency groups

Regarding "snapping" multiple LUNs in a zpool:

EMC arrays (at least on the Symmetrix) have this concept of "consistency
groups" which are essentially a way of doing "atomic"
BCVs/Clones/Sparse-clones on "groups" of disks. That should allow the
proper use of BCVs in ZFS land without too much of an issue. (being able
to do zfs-snapshots atomically on entire zpools (which would therefore
cover ALL volume etc.) would be a great feature, which I think is
already an RFE for zfs).

One thing that might cause some difficulty is the "importing" of the
cloned disk-set back onto the SAME system. Doing this with VxVM requires
some "vxprivutil" monkey business, since otherwise VxVM would get
confused by the same disk-groups/signatures being available in multiple
locations. (I would assume zfs would also have an issue seeing the same
"zpool" twice on the same system.)

What kind of ZFS magic would be needed to allow this to work?
(essentially changing the pool-name of a zpool before importing it? As I
don''t think you''ll be able to address the "cloned
pool" with the name of
the original pool upon import back to the same host... Even if you give
it another zpool name upon import..... I haven''t tried this in the lab,
I''ll go play around a little..... Anyone else already do this? Is there
a work-around or RFE already?)

--

Back to EMC land, "federated snaps" or concistency-groups "across
arrays" was a challenge but I think that has also been delivered, but
I''m been away from that space for a bit.

Basically what this seems to come down to is that for SOME
systems/customers/configurations, its important to use the array to
CLONE zpools, and have the ability to import that CLONED zpool onto
either the same hosts, or ANOTHER host. In cases where a
zbackup/zrestore would cause too much churn, doing it at the array-level
is a nice alternative to have.

My 2 cents,

 -- MikeE



-----Original Message-----
From: zfs-discuss-bounces at opensolaris.org
[mailto:zfs-discuss-bounces at opensolaris.org] On Behalf Of Robert
Milkowski
Sent: Thursday, April 27, 2006 2:38 AM
To: Torrey McMahon
Cc: zfs-discuss at opensolaris.org; Richard Elling
Subject: Re[2]: [zfs-discuss] Re: Shrinking a zpool?


Hello Torrey,

Thursday, April 27, 2006, 5:42:50 AM, you wrote:

TM> Robert Milkowski wrote:
>> Hello Richard,
>>
>> Wednesday, April 26, 2006, 8:50:20 PM, you wrote:
>>
>> RE>  From what I know of your situation, ZFS would be ideal because:
>> RE>         1. the on-disk data is always consistent -- ideal for
BCVs
>>
>> Well, I''m still not convinced with ZFS + BCVs - snapshots, no
problems. But normal
>> filesystems - were, they can get corrupted and right now it could
lead
>> to system panic.

TM> The issue with taking a snapshot at the volume/lun level is that all
of
TM> the volumes/luns in the zpool would need to be snapped at the same
time.
TM> Otherwise the pool itself would not be consistent within the
snapshot.
TM> If you have one BCV that backed your zpool then it should work. If
you
TM> have ten LUNs in a zpool and you need to issue ten BCV operations,
one
TM> to each LUN, you might not be able to do it in a fashion that would 
TM> ensure consistency. (Not knowing exactly how BCVs work I can''t
say
one
TM> way or an other.)

TM> Here''s a silly example: Put two LUNs in a zpool. Snapshot one.
Wait
ten
TM> minutes while doing i/o to the pool. Replace one, and only one, of
the
TM> LUNs with it''s snapshot from ten minutes. Me thinks
you''ll see some
TM> problems.

Exactly my point. That''s why I think ZFS is not well suited for BCV
like functionality - ok, I haven''t checked it myself (yet) but it just
can''t work properly every time with many luns/bcvs.

And I don''t think that snapshot for a whole pool is needed - rather
something like ''zpool lock pool_name'' - so entire pool is
guaranteed
to be consistent on disk and no new modifications will occur (reads
are ok) as lon as one specify ''zpool unlock pool_name''. It
works that
way on EMC celerra.

-- 
Best regards,
 Robert                            mailto:rmilkowski at task.gda.pl
                                       http://milek.blogspot.com

_______________________________________________
zfs-discuss mailing list
zfs-discuss at opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss