My last post hopefully shed a little light on file system requirements for iSCSI luns on the EMC Celerra when replication or snapshots will be used. If you missed this and you think it might be of interest you can read it here.
First lets verify what the current value for sparseTWS is set to
[nasadmin@EMCNAS ~]$ server_param server_2 -f nbs -i sparseTws
server_2 :
name = sparseTws
facility_name = nbs
default_value = 0
current_value = 0
configured_value =
user_action = none
change_effective = immediate
range = (0,1)
description = Enables sparse TWS support
server_2 : done
You can see the default and current value are both set to zero which means this feature is currently not in use.
Now lets enable support for spareTWS
[nasadmin@EMCNAS~]$ server_param server_2 -f nbs -m sparseTws -v 1
server_2 :
name = sparseTws
facility_name = nbs
default_value = 0
current_value = 1
configured_value = 1
user_action = none
change_effective = immediate
range = (0,1)
description = Enables sparse TWS support
[nasadmin@EMCNAS ~]$
Also to verify this has been enabled correctly you can also browse using Celerra Manager to the Data Mover parameters tab, if correctly enabled you should see an entry called sparseTWS with a vaule of 1.
What uses Tempoary Writable Snapshots ?
SRM is a good example, every time you hit that “TEST” button SRM via the SRA (Storage Replication Adapter) is creating a Temporary Writable Snapshot of the replicated lun and presenting it to the ESX host configured at the recovery site.
Replication Manager is another good example of an application that takes advantage of the Celerra Temporary writable snapshots. Ive configured our Replication Manager server to snapshot our production VMware iSCSI luns which I then present to another ESX host which we refer to as the mount host. Once Ive done testing or backing up the data I cant then un mount and remove the TWS.
By configuring the sparseTWS option with fully provisioned luns, we reduce the file system needed by the size of the published lun.
