Recommended best practices for writable snapshots on OneFS include:

• Not exceeding the default OneFS limit of 30 active writable snapshots per cluster. If the max_active_wsnaps limit is increased for some reason, do not attempt to delete more than 30 writable snapshots at a time.
• The writable snapshots feature can be enabled and disabled using a sysctl. However, disabling it will not affect any existing writable snapshots.
• In OneFS 9.3 and later, the primary focus of writable snapshots is for DR testing. Although writable snapshots cannot use SyncIQ-generated snapshots, a separate read-only snapshot can be taken of the replicated dataset and used as a writable snapshot source.
• Writable snapshots cannot be refreshed from a newer read-only source snapshot. However, a new writable snapshot can be created from a more current source snapshot in order to include subsequent updates to the replicated production dataset.
• While the contents of a writable snapshot will retain the permissions they had in the source, ensure the parent directory tree has appropriate access permissions for the users of the writable snapshot.
• Writable snapshots are highly space efficient, however the savings are strictly in terms of file data. Metadata will be consumed in full for each file and directory in a snapshot. So, for large sizes and quantities of writable snapshots, inode consumption should be considered, especially for metadata read and metadata write SSD strategies.
• Writable snapshots do not support OneFS deduplication or small file storage efficiency.
• Writable snapshot configuration and management is performed solely using the CLI or platform API, and there are no corresponding WebUI controls available in OneFS 9.3 and later.
• If automation of the writable snapshot life cycle is required, it can be scripted using the OneFS PlatformAPI. However, in OneFS 9.3 and later, there is no support for policy-driven writable snapshot creation. Similarly, writable snapshots cannot currently be batch deleted and can only be manually deleted one at a time.
• The ‘ISI_PRIV_SNAPSHOT’ roles-based administration privilege is required for configuring and managing writable snapshots and, as such, their creation and deletion can be authorized and audited based on ‘isi auth’ roles.
• The recommended practice is to quiesce any client sessions to a writable snapshot before its deletion. Since the backing snapshot can no longer be trusted once its lock is removed during the deletion process, any ongoing IO may experience errors as the writable snapshot is removed.
• If the deletion and cleanup of a writable snapshot fails for some reason, it can be removed from its top-level directory using its renamed path (*.deleted). For example:

# isi snap writable delete /ifs/test/wsnap2.51dc245eb.deleted

• There are certain caveats governing where a writable snapshot’s mount point can reside in the file system. These locations include not at an existing directory, below a source snapshot path, or under a SmartLock or SyncIQ domain.
• A writable snapshot cannot be created from a source snapshot of the /ifs root directory.
• Taking a read-only snapshot of a writable snapshot is not permitted in OneFS 9.3 and later releases.
• A writable snapshot cannot be locked or changed to read-only. However, the read-only source snapshot will be locked for the entire life cycle of a writable snapshot.
• Writable snapshots in OneFS 9.3 and later cannot be replicated using SyncIQ or backed up over NDMP.
• Snapshot aliases cannot be used as the source of a writable snapshot, even if using the alias target ID in place of the alias target name
• Most Job Engine jobs can be run from inside a writable snapshot path. However, certain jobs like SmartDedupe and SmartPools will run but not be able to enact their function (such as deduplicate or tier data) upon writable snapshot files and namespace.