+1 When I did my stuff (with a major bank) two years ago, my reasoning was that we (Sun, remember them?) had made huge capital out of the "always consistent on disk" claim, and that we could be expected to stand by and honour that promise.
But because this was a big bank, I felt that due dilligence required that I should call up the ultimate authorities (the ZFS architects and implementors) for confirmation that what I was intending was based on rock solid assumptions. Having obtained those assurances, we went ahead and did implemented some impressive, rule changing, business enabling stuff. zfs send | recv is cool technology, but it is not the only show in town. The downsides include: it's slow; that it impacts the performance of the sending system; that there's no easy way to know if continuous sending of incremental changes will be able to keep up with demand; etc LUN snapshots are, by comparison, free at the point of use (no impact on the sending system), and practically instant. And of course, there's nothing to stop both techniques being used together (e.g. take a LUN snapshot, import the pool into another host, and do the zfs send there, where it has no impact on the performance of the live system). And of course, there are independent, experienced, expert people of integrity out there you can always hire to help you implement such schemes safely and wisely. Phil www.harmanholistix.com On 17 Nov 2010, at 00:19, Tim Cook <t...@cook.ms> wrote: > > 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. > > > > 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? > > > > 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. > > --Tim > _______________________________________________ > zfs-discuss mailing list > zfs-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
