On Wed, Nov 17, 2010 at 2:56 PM, Jim Dunham <james.dun...@oracle.com> wrote:
> 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. > How is using an array based snapshot to create a copy of a filesystem "non-standard"? Non-standard to who? Array based snapshots were around long-before ZFS was created. It was proven and documented long before ZFS was around as well. Given your history in the industry, I know you aren't so new to this game you didn't already know that, so I'm not really sure what the purpose of "proven and documented" was, other than to try to insinuate that other technologies are not. > > > > >> > 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. > > The array doesn't "update the snapshot data". That's the whole point of the snapshot. It's point-in-time. Either the snapshot exists as it was taken, or it's deleted. What array on the market changes blocks in a snapshot that are being presented out as a live filesystem to a host? I've never heard of any such behavior, and that sort of behavior would be absolutely brain-dead. 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. > > Except when it isn't. Which is why zfs import -F was added to ZFS. In theory ZFS doesn't need checkdisk and it didn't need an import -F because it's always consistent on disk. In reality, that's utterly false as well. > 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. > > > If the zpool is exported or the system is shutdown, there won't be any access from any applications --Tim
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
