Tim, > > On Wed, Nov 17, 2010 at 10:12 AM, Jim Dunham <james.dun...@oracle.com> wrote: > sridhar, > > > I have done the following (which is required for my case) > > > > Created a zpool (smpool) on a device/LUN from an array (IBM 6K) on host1 > > created a array level snapshot of the device using "dscli" to another > > device which is successful. > > Now I make the snapshot device visible to another host (host2) > > Even though the array is capable of taking device/LUN snapshots, this is a > non-standard mode of operation regarding the use of ZFS. > > It raises concerns that if one had a problem using a ZFS in this manner, > there would be few Oracle or community users of ZFS that could assist. Even > if the alleged problem was not related to using ZFS with array based > snapshots, usage would always create a level of uncertainty. > > Instead I would suggest using ZFS send / recv instead. > > > That's what we call FUD. "It might be a problem if you use someone else's > feature that we duplicate". If Oracle isn't going to support array-based > snapshots, come right out and say it. You might as well pack up the cart now > though, there isn't an enterprise array on the market that doesn't have > snapshots, and you will be the ONLY OS I've ever heard of even suggesting > that array-based snapshots aren't allowed.
That's not what I said... Non-standard mode of operation is not the same thing as not supported. Using ZFS's standard mode of operation based on its built-in support for snapshots is well proven, well document technology. > > > > would there be any issues ? > > Prior to taking the next snapshot, one must be assured that the device/LUN on > host2 is returned to the "zpool export" state. Failure to do this could cause > zpool corruption, ZFS I/O failures, or even the possibility of a system panic > on host2. > > > Really? And how did you come to that conclusion? As prior developer and project lead of host-based snapshot and replication software on Solaris, I have first hand experience using ZFS with snapshots. If while ZFS on node2 is accessing an instance of snapshot data, the array updates the snapshot data, ZFS will see newly created CRCs created by node1. These CRCs will be considered as metadata corruption, and depending on exactly what ZFS was doing at the time the corruption was detected, the software attempt some form of error recovery. > OP: Yes, you do need to use a -f. The zpool has a signature that is there > when the pool is imported (this is to keep an admin from accidentally > importing the pool to two different systems at the same time). The only way > to clear it is to do a zpool export before taking the initial snapshot, or > doing the -f on import. Jim here is doing a great job of spreading FUD, and > none of it is true. > > What you're doing should absolutely work, just make sure there is no I/O in > flight when you take the original snapshot. > > Either export the pool first (I would recommend this approach), shut the > system down, or just make sure you aren't doing any writes when taking the > array-based snapshot. These last two statements need clarification. ZFS is always on disk consistent, even in the context of using snapshots. Therefore as far as ZFS is concerned, there is no need to assure that there are no I/Os in flight, or that the storage pool is exported, or that the system is shutdown, or that one is doing any writes. Although ZFS is always on disk consistent, many applications are not filesystem consistent. To be filesystem consistent, an application by design must issue careful writes and/or synchronized filesystem operations. Not knowing this fact, or lacking this functionality, a system admin will need to deploy some of the work-arounds suggested above. The most important one not listed, is to stop or pause those applications which are know not to be filesystem consistent. - Jim > > --Tim
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
