XigmaNAS

I recently encountered cryptolocker on several Windows systems, it was unpleasant. I thought by using an iSCSI drive on a N4F zfs volume I could use zfs rollback to quickly recover from future data loses. I was testing such a scenario by using a win10 system where D: is the N4F iSCSI drive, copy files to it, shutdown the system and then rollback to some point to see what happens.

Version 10.3.0.3 - Pilingitam (revision 2942)

nas4free: ~# zfs list
NAME USED AVAIL REFER MOUNTPOINT
miniPool 1.49T 3.65T 1.35T /mnt/miniPool
miniPool/iSCSI01 148G 3.75T 46.5G -
nas4free: ~#
nas4free: ~# zfs list -t snapshot
NAME USED AVAIL REFER MOUNTPOINT
miniPool/iSCSI01@autosnap_2016-09-13_23:09:34_daily 0 - 44.5G -
miniPool/iSCSI01@autosnap_2016-09-13_23:09:34_monthly 0 - 44.5G -
miniPool/iSCSI01@autosnap_2016-09-14_00:00:00_daily 0 - 44.5G -
miniPool/iSCSI01@autosnap_2016-09-14_01:00:00_hourly 0 - 44.5G -
miniPool/iSCSI01@autosnap_2016-09-14_02:00:00_hourly 0 - 44.5G -
miniPool/iSCSI01@autosnap_2016-09-14_03:00:00_hourly 0 - 44.5G -
miniPool/iSCSI01@autosnap_2016-09-14_04:00:00_hourly 0 - 44.5G -
miniPool/iSCSI01@autosnap_2016-09-14_05:00:00_hourly 0 - 44.5G -
miniPool/iSCSI01@autosnap_2016-09-14_06:00:00_hourly 0 - 44.5G -
miniPool/iSCSI01@autosnap_2016-09-14_07:00:01_hourly 0 - 44.5G -
miniPool/iSCSI01@autosnap_2016-09-14_08:00:00_hourly 0 - 44.5G -
miniPool/iSCSI01@autosnap_2016-09-14_09:00:00_hourly 8.23M - 46.4G -
miniPool/iSCSI01@autosnap_2016-09-14_10:00:00_hourly 0 - 46.5G -
miniPool/iSCSI01@autosnap_2016-09-14_11:00:00_hourly 0 - 46.5G -
miniPool/iSCSI01@autosnap_2016-09-14_12:00:00_hourly 0 - 46.5G -
miniPool/iSCSI01@autosnap_2016-09-14_13:00:00_hourly 0 - 46.5G -

nas4free: ~# zfs rollback -r miniPool/iSCSI01@autosnap_2016-09-14_08:00:00_hourly
cannot rollback 'miniPool/iSCSI01': dataset is busy
nas4free: ~# zfs list -t snapshot
NAME USED AVAIL REFER MOUNTPOINT
miniPool/iSCSI01@autosnap_2016-09-13_23:09:34_daily 0 - 44.5G -
miniPool/iSCSI01@autosnap_2016-09-13_23:09:34_monthly 0 - 44.5G -
miniPool/iSCSI01@autosnap_2016-09-14_00:00:00_daily 0 - 44.5G -
miniPool/iSCSI01@autosnap_2016-09-14_01:00:00_hourly 0 - 44.5G -
miniPool/iSCSI01@autosnap_2016-09-14_02:00:00_hourly 0 - 44.5G -
miniPool/iSCSI01@autosnap_2016-09-14_03:00:00_hourly 0 - 44.5G -
miniPool/iSCSI01@autosnap_2016-09-14_04:00:00_hourly 0 - 44.5G -
miniPool/iSCSI01@autosnap_2016-09-14_05:00:00_hourly 0 - 44.5G -
miniPool/iSCSI01@autosnap_2016-09-14_06:00:00_hourly 0 - 44.5G -
miniPool/iSCSI01@autosnap_2016-09-14_07:00:01_hourly 0 - 44.5G -
miniPool/iSCSI01@autosnap_2016-09-14_08:00:00_hourly 0 - 44.5G -

The rollback to miniPool/iSCSI01@autosnap_2016-09-14_08:00:00_hourly deleted the previous snapshots as expected but then couldn't complete the actual rollback.

This is problematic on a couple of levels. Firstly, the more recent snapshots are gone, secondly, I can't figure why the dataset is busy.

Any insight would be appreciated.

Well, I now know that the dataset really is busy. There are only a couple of places in the FreeBSD code where the string "cannot rollback 'miniPool/iSCSI01': dataset is busy" could be generated. It seems one of the zfs related IOCtl calls returns EBUSY resulting in the message. Without using dtrace or instrumenting BSD with debugging printouts I will never "deduce" whats making it busy. In the "Managing ZFS File Systems in Oracle® Solaris 11.2" documentation I found this:

A ZFS volume as an iSCSI target is managed just like any other ZFS dataset, except that you cannot rename the dataset, roll back a volume snapshot, or export the pool while the ZFS volumes are shared as iSCSI LUNs. You will see messages similar to the following:
# zfs rename tank/volumes/v2 tank/volumes/v1
cannot rename 'tank/volumes/v2': dataset is busy
# zpool export tank
cannot export 'tank': pool is busy

Sounds like my situation. I then disabled the iSCSI Target at Services|iSCSI Target|settings. This allowed the rollback to proceed and it completed successfully. I reenabled the iSCSI Target, booted the test system and indeed the D: drive had been rolled back.