Is a ZVOL protected by the raidz configuration under it?

[Paul Morris]

I ran into an issue trying to use send/receive from Solaris to Freenas. Seems there is an incompatibility issue between the two versions which require some special setup gyrations to overcome. If instead I create a zvol and mount that using iSCSI on the Solaris system and create a ZFS pool on that, does the underlying Freenas RAIDZ2 configuration protect the data stored on the ZVOL as if in fact it were ZFS data set defined on the Freenas?

I intend to do some experiments to check this out but was just curious if anyone had any experience with this type of configuration. I have about 8TB of data contained in 5 separate ZVOLs in this configuration and really don't want to take a chance at losing it. Since the Solaris pool has no redundancy on the Solaris side and is just basically a single disk drive, what kind of problems could I expect on the Solaris side of things if one of the devices underlying the ZVOL had a problem.

What about snapshots, is a ZVOL considered a single file on the ZFS pool and does a snapshot retain changes on the ZVOL?

Was this a bad idea to use ZVOLs in this manner?

 

[rs225]

The answers to your overall questions are yes.

If you don't want to lose the data, then it needs to exist in at least two places. From your description, it isn't clear whether that is true.

 

[Ericloewe]

does the underlying Freenas RAIDZ2 configuration protect the data stored on the ZVOL as if in fact it were ZFS data set defined on the Freenas?

Yes, obviously. Why else would anyone bother?

What about snapshots, is a ZVOL considered a single file on the ZFS pool and does a snapshot retain changes on the ZVOL?

Snapshots happen at the block level. Did a block change? It's been snapshotted.

 

[Paul Morris]

After a quick test ... created a ZVOL on the Freenas tank/testvol and setup the iSCSI parameters, attached the device to my Solaris machine, created a ZPOOL on the device and a data set testpool/testds. I then filled the data set with some files and did a snapshot on the Freenas. Everything looks good. I then deleted a number of big files from the Solaris dataset and did another snapshot on the Freenas. Looks promising ... the first snapshot has increased in size which means I got something in the snapshot. OK, so let's rollback to the first snapshot and see what happens... OOPS ... got nothing back on the Solaris side. Humm... wonder why... let's think about this a bit. As I understand it ZFS is a block level device manager and doesn't like to have any kind of RAID hardware under it . Since I have a pool defined on what appears to be a block device (but it really is a RAID of some sort) ZFS on Solaris is not really getting what it thinks it is getting and is managing the filesystem locally, unaware of an underlying ZFS pool on the Freenas. So any changes in the underlying Freenas pool are possibly damaging to the Solaris ZFS file system.

Looks like I need to come up with a better idea. Any good ideas out there??

 

[jgreco]

Why would you even think that would work?

You can't just roll back a snapshot of a zvol and expect that some remote machine that's using it (especially with a cache-y filesystem like ZFS on top) would have any clue as to how to cope with that.

 

[genBTC]

Why would you even think that would work?

You can't just roll back a snapshot of a zvol and expect that some remote machine that's using it (especially with a cache-y filesystem like ZFS on top) would have any clue as to how to cope with that.

About this comment, assuming I were running NTFS on the iSCSI block device, dismounted the iSCSI share from my client, rolled back into a ZFS snapshot, and re-mount the iSCSI device, would this be ok for the NTFS system assuming it were properly dismounted in between snaps?

 

[rs225]

@genBTC that would work. The critical part is disconnecting the client for the rollback. On the other hand, a snapshot that is made without disconnecting will look like a power failure if ever used. Some filesystems/apps can handle that, others not.