[OpenIndiana-discuss] ZfS migration scenario including zvols

[Sebastian Gabler]

Hi Edward,

thanks for your comment. Indeed, after reading it I went back to the opensolaris mail archive and found a couple of threads that expand on zfs send integrity extensively, back in 2009. Among others, Richard Elling and you were the most active contributors.

In my case, from the aspect of zpools I could have done easily what you suggest, to pipe send through a receive to a different zpool because it was a local transfer.
The reason why I chose dumping streams to file was because I figured that would be an easy way to avoid any tempering with the data while they sit in temp to be re-transferred to their original place.
>From what I understand now, I could have been bitten badly in case the first transfer went wrong. As the final receive went fine, I am sure that the streams weren't corrupted in a way that zfs would be aware of.

Now I know that maybe I should have run zfs recv -n or  zstreamdump from the dumps before destroying the original pool. Next time I will certainly do so.
I have also learned that there are obviously methods to prevent a replicated stream from mounting. But I still wonder how exactly I should have proceeded here to achieve that the replicated data could not be tempered with while waiting for their repatriation.

Remains the size difference I noted: zfs used param read 1 GB less than in the original data sets (per leaf data set!). As all VMs booted well from the nfs shares, and so did the ntfs volumes that run from Comstar targets, and they run all happily for two days, I do not think that salience has to do with stream corruption. The old pool and data sets were originally created 3 years ago on OSOL2009.6 , and it was raidz2. Maybe rather a change of implementation of nice numbers representation, or a rounding error in reading the size is the reason for this.

Best regards,

Sebastian
 
>From: "Edward Ned Harvey (openindiana)" <openindiana at nedharvey.com>
>To: Discussion list for OpenIndiana
><openindiana-discuss at openindiana.org>
>Subject: Re: [OpenIndiana-discuss] ZfS migration scenario including
>zvols
>Message-ID:
><D1B1A95FBDCF7341AC8EB0A97FCCC4773BBCD1CB at SN2PRD0410MB372.namprd04.prod.outlook.com>

>Content-Type: text/plain; charset="us-ascii"

>> From: Sebastian Gabler [mailto:sequoiamobil at gmx.net]
>> Sent: Saturday, April 13, 2013 11:38 AM
>>
>> - zfs send mainbranch at 1 -R > /pool2/mainbranch.dmp for each nfs, iscsi,
>> smb

>It is advisable, if possible, to create a new zpool with your new tmp storage, and zfs send | zfs >receive. (Don't store a zfs send data stream in a file.) Because the "zfs receive" does all the >cksumming, and will detect and notify you in the event of a data transmission problem.

>But if all you have is a network store, or something else that you can't format with zfs for some >reason... So be it. You do what you have to do.