The scale and demands of unstructured data continue to grow at a relentless rate, making the need for optimized file-based data storage, and its simplified management, more crucial than ever.

OneFS writable snapshots help customers maximize the long-term value of their critical business data and drive down storage management cost and complexity. This simple, scalable solution offers fast, space-efficient, consistent copies of large datasets on Dell PowerScale NAS storage.

This white paper presents information for managing writable snapshots in a Dell PowerScale cluster. This document does not intend to provide a comprehensive background to the OneFS architecture.

See the OneFS Technical Overview white paper for further details about the OneFS architecture.

The target audience for this white paper is anyone configuring and managing writable snapshots within a OneFS-powered clustered storage environment. It is assumed that the reader has an understanding and working knowledge of the OneFS components, architecture, commands, and features.

More information about OneFS commands and feature configuration is available in the OneFS Administration Guide.

Dell Technologies and the authors of this document welcome your feedback on this document. Contact the Dell Technologies team by email.

Author: Nick Trimbee

Note: For links to other documentation for this topic, see the PowerScale Info Hub.

Writable snapshots are a data storage technique for generating temporary copies of a ‘golden’ dataset, while eliminating unnecessary duplication of data and the resulting capacity overhead.

Traditional methods of copying entire directory trees are often costly, both in terms of storage consumption and administrative overhead. They often rely on creating writable copies of a directory tree through:

• A simple recursive copy, which is expensive in terms of time and storage.
• Recursively cloning a directory, which is typically a lengthy serial operation.
• Replication (either locally or to a remote target), which is both capacity and time consuming.

Dell PowerScale writable snapshots, available in OneFS 9.3 and later, gives you the ability to create fast, simple, efficient copies of datasets. It enables a writable view of a regular snapshot that is presented at a target directory and is accessible by clients across the full range of supported NAS protocols.

OneFS writable snapshots enable the creation and management of a space- and time-efficient, modifiable copy of a regular OneFS snapshot. As such, the snapshots present a writable copy of a source snapshot that is accessible at a directory path within the /ifs namespace. You can access and edit the snapshot through any of the cluster’s file and object protocols, including NFS, SMB, and S3.

The writable snapshot architecture provides an overlay to a read-only source snapshot. This overlay allows a cluster administrator to create a lightweight copy of a production dataset using a simple CLI command, and present and use it as a separate writable namespace.

Figure 1.   OneFS writable snapshot architecture

In the scenario above, a SnapshotIQ snapshot (snap_prod_1) is taken of the /ifs/prod directory. The read-only ‘snap_prod_1’ snapshot is then used as the backing for a writable snapshot created at /ifs/wsnap. This writable snapshot contains the same subdirectory and file structure as the original ‘prod’ directory, but without the added data capacity footprint.

Internally, OneFS 9.3 and later support a new protection group data structure, ‘PG_WSNAP’. This structure provides an overlay that allows unmodified file data to be read directly from the source snapshot, while storing only the changes in the writable snapshot tree.

Figure 2.   OneFS writable snapshot block overlay and redirection

In this example, a file (Head) consists of four data blocks, A through D. A read-only snapshot is taken of the directory containing the Head file. This file is then modified through a copy-on-write operation. As a result, the new Head data, B1, is written to block 102, and the original data block ‘B’ is copied to a new physical block (110). The snapshot pointer now references block 110 and the new location for the original data ‘B’, so the snapshot has its own copy of that block.

Next, a writable snapshot is created using the read-only snapshot as its source. This writable snapshot is then modified, so its updated version of block C is stored in its own protection group (PG_WSNAP). A client then issues a read request for the writable snapshot version of the file. This read request is directed, through the read-only snapshot, to the Head versions of blocks A and D, the read-only snapshot version for block B, and the writable snapshot file’s own version of block C (C1 in block 120).

OneFS directory quotas provide the writable snapshots accounting and reporting infrastructure, allowing users to easily view the space utilization of a writable snapshot. Also, IFS domains are also used to bound and manage writable snapshot membership. In OneFS, a domain defines a set of behaviors for a collection of files under a specified directory tree. If a directory has a protection domain applied to it, that domain will also affect all the files and subdirectories under that top-level directory.

When files within a newly created writable snapshot are first accessed, data is read from the source snapshot, populating the files’ metadata, in a process known as copy-on-read (CoR). Unmodified data is read from the source snapshot and any changes are stored in the writable snapshot’s namespace data structure (PG_WSNAP).

Since a new writable snapshot is not copy-on-read up front, its creation is extremely rapid. As files are accessed later, they are enumerated and begin to consume metadata space.

On accessing a writable snapshot file for the first time, a read is triggered from the source snapshot and the file’s data is accessed directly from the read-only snapshot. At this point, the MD5 checksums for both the source file and writable snapshot file are identical. If, for example, the first block of file is overwritten, only that single block is written to the writable snapshot. Then, the remaining unmodified blocks are still read from the source snapshot. At this point, the source and writable snapshot files are now different, so their MD5 checksums will also differ.

Before writable snapshots can be created and managed on a cluster, the following prerequisites must be met:

• The cluster is running OneFS 9.3 or later with the upgrade committed.
• SnapshotIQ is licensed across the cluster.

Note: For replication environments using writable snapshots and SyncIQ, all target clusters must be running OneFS 9.3 or later, have SnapshotIQ licensed, and provide sufficient capacity for the full replicated dataset.

By default, up to thirty active writable snapshots can be created and managed on a cluster using the following methods:

• OneFS command-line interface (CLI)
• OneFS RESTful platform API

The CLI subcommands and syntax for writable snapshots are as follows:

# isi snapshot writable -h

Description:

    Manage writable snapshots.

Required Privileges:

    ISI_PRIV_SNAPSHOT

Usage:

    isi snapshot writable <action>

        [--timeout <integer>]

        [{--help | -h}]

Actions:

    create    Create a writable snapshot.

    delete    Delete writable snapshots.

    list      View a list of writable snapshots.

    view      View properties of a writable snapshot.

Options:

  Display Options:

    --timeout <integer>

        Number of seconds for a command timeout (specified as 'isi --timeout NNN

        <command>').

    --help | -h

        Display help for this command.

See 'isi snapshot writable <subcommand> --help' for more information on a

specific subcommand.

Similarly, the platform API primitives can be viewed by browsing the following cluster URL: https://<cluster_IP>:8080/platform/14/snapshot/writable?describe

On creation of a new writable snapshot, all files contained in the snapshot source, or HEAD directory tree, are instantly available for both reading and writing in the target namespace. Once it is no longer required, a writable snapshot can be easily deleted by CLI.

Note: There are no corresponding WebUI controls for configuring writable snapshots.

In OneFS 9.3 and later releases, a writable snapshot can easily be created from the CLI with the following command syntax.

Usage:

isi snapshot writable create <src-snap> <dst-path>

The source snapshot (src-snap) is an existing read-only snapshot (prod1), and the destination path (dst-path) is a new directory within the /ifs namespace (/ifs/test wsnap1). A read-only source snapshot can be generated as follows:

# isi snapshot snapshots create prod1 /ifs/test/prod

# isi snapshot snapshots list

ID     Name                             Path

-------------------------------------------------------

7142   prod1      /ifs/test/prod

More information about configuring and managing OneFS SnapshotIQ is available in the document Data Protection with Dell PowerScale SnapshotIQ.

Next, the following command creates a writable snapshot in an ‘active’ state.

# isi snapshot writable create prod1 /ifs/test/wsnap1

# isi snapshot snapshots delete -f prod1

Snapshot "prod1" can't be deleted because it is locked

While the OneFS CLI is not explicitly prevented from unlocking a writable snapshot’s lock on the backing snapshot, it does provide a clear warning.

# isi snap lock view prod1 1

     ID: 1

Comment: Locked/Unlocked by Writable Snapshot(s), do not force delete lock.           

Expires: 2106-02-07T06:28:15

  Count: 1

# isi snap lock delete prod1 1

Are you sure you want to delete snapshot lock 1 from s13590? (yes/[no]):

Be aware that a writable snapshot cannot be created on an existing directory. A new directory path must be specified in the CLI syntax, otherwise the command will fail with the following error:

# isi snapshot writable create prod1 /ifs/test/wsnap1

mkdir /ifs/test/wsnap1 failed: File exists

Similarly, if an unsupported path is specified, the following error will be returned:

# isi snapshot writable create prod1 /isf/test/wsnap2

Error in field(s): dst_path

Field: dst_path has error: The value: /isf/test/wsnap2 does not match the regular expression: ^/ifs$|^/ifs/ Input validation failed.

A writable snapshot also cannot be created from a source snapshot of the /ifs root directory, and will fail with the following error:

# isi snapshot writable create s1476 /ifs/test/ifs-wsnap

Cannot create writable snapshot from a /ifs snapshot: Operation not supported

OneFS 9.3 and later releases do not support scheduled or automated writable snapshot creation.

When it comes to deleting a writable snapshot, OneFS uses the job engine’s TreeDelete job under the hood to unlink all the contents. As such, running the ‘isi snapshots writable delete’ CLI command automatically queues a TreeDelete instance. The job engine runs this instance asynchronously to remove and clean up a writable snapshot’s namespace and contents. However, be aware that the TreeDelete job execution, and hence the data deletion, is not instantaneous. Instead, the writable snapshot’s directories and files are moved under a temporary ‘*.deleted’ directory. For example:

# isi snapshot writable create prod1 /ifs/test/wsnap2

# isi snap writable delete /ifs/test/wsnap2

Are you sure? (yes/[no]): yes

# ls /ifs/test

prod                            wsnap2.51dc245eb.deleted

wsnap1

Next, this temporary directory is removed in a non-synchronous operation. If the TreeDelete job fails for some reason, the writable snapshot can be deleted using its renamed path. For example:

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

Note: Deleting a writable snapshot removes the lock on the backing read-only snapshot so it can also be deleted, if required. It can be deleted if there are no other active writable snapshots based off that read-only snapshot.

The deletion of writable snapshots in OneFS 9.3 and later is a manual process. There is no provision for automated, policy-driven control such as the ability to set a writable snapshot expiry date, or a bulk snapshot deletion mechanism.

In general, the ‘isi writable snapshots’ CLI syntax looks and feels similar to regular, read-only snapshots under OneFS. The currently available writable snapshots on a cluster can be easily viewed from the CLI with the ‘isi snapshot writable list’ command. For example:

# isi snapshot writable list

Path              Src Path        Src Snapshot

----------------------------------------------

/ifs/test/wsnap1  /ifs/test/prod  prod1

/ifs/test/wsnap2  /ifs/test/snap2 s73736

----------------------------------------------

The properties of a particular writable snapshot, including both its logical and physical size, can be viewed using the ‘isi snapshot writable view’ CLI command. For example:

# isi snapshot writable view /ifs/test/wsnap1

         Path: /ifs/test/wsnap1

     Src Path: /ifs/test/prod

 Src Snapshot: s73735

      Created: 2021-06-11T19:10:25

 Logical Size: 100.00

Physical Size: 32.00k

        State: active

OneFS SmartQuotas provides the capacity resource accounting for writable snapshots. The physical, logical, and application logical-space usage is retrieved from a directory quota on the writable snapshot’s root. This usage can be viewed directly from the OneFS CLI as follows: 

# isi quota quotas list

Type      AppliesTo  Path             Snap  Hard  Soft  Adv  Used  Reduction  Efficiency

-----------------------------------------------------------------------------------------

directory DEFAULT    /ifs/test/wsnap1 No    -     -     -    76.00 -          0.00 : 1

-----------------------------------------------------------------------------------------

Or from the OneFS WebUI by going to Storage > Quotas > Quotas and Usage, or File system > SmartQuotas > Quotas and usage in OneFS 9.14 and earlier releases:

Figure 3.   OneFS SmartQuotas WebUI usage dashboard

For more detail, the ‘isi quota quotas view’ CLI command provides a thorough appraisal of a writable snapshot’s directory quota domain. This information includes physical, logical, and storage efficiency metrics plus a file count. For example:

# isi quota quotas view /ifs/test/wsnap1 directory

                        Path: /ifs/test/wsnap1

                        Type: directory

                   Snapshots: No

                    Enforced: Yes

                   Container: No

                      Linked: No

                       Usage

                           Files: 10

         Physical(With Overhead): 32.00k

        FSPhysical(Deduplicated): 32.00k

         FSLogical(W/O Overhead): 76.00

        AppLogical(ApparentSize): 0.00

                   ShadowLogical: -

                    PhysicalData: 0.00

                      Protection: 0.00

     Reduction(Logical/Data): None : 1

Efficiency(Logical/Physical): 0.00 : 1

                        Over: -

               Thresholds On: fslogicalsize

              ReadyToEnforce: Yes

                  Thresholds

                   Hard Threshold: -

                    Hard Exceeded: No

               Hard Last Exceeded: -

                         Advisory: -

    Advisory Threshold Percentage: -

                Advisory Exceeded: No

           Advisory Last Exceeded: -

                   Soft Threshold: -

        Soft Threshold Percentage: -

                    Soft Exceeded: No

               Soft Last Exceeded: -

                       Soft Grace: -

This information is also available from the OneFS WebUI by going to Storage > Quotas Generated Reports Archive, or File system > SmartQuotas > Generated reports archive > View report details in OneFS 9.14 and earlier releases. For example:

Figure 4.   OneFS SmartQuotas WebUI usage report

Also, the ‘isi get’ CLI command can be used to inspect the efficiency of individual writable snapshot files. First, run the following command syntax on the chosen file in the source snapshot path (in this case /ifs/test/source). 

Note: In the example below, the source file, /ifs//test/prod/testfile1, is reported as 147 MB in size and occupying 18019 physical blocks:

# isi get -D /ifs/test/prod/testfile1.zip

POLICY   W   LEVEL PERFORMANCE COAL  ENCODING      FILE              IADDRS

default      16+2/2 concurrency on    UTF-8         testfile1.txt        <1,9,92028928:8192>

*************************************************

* IFS inode: [ 1,9,1054720:512 ]

*************************************************

*

*  Inode Version:      8

*  Dir Version:        2

*  Inode Revision:     145

*  Inode Mirror Count: 1

*  Recovered Flag:     0

*  Restripe State:     0

*  Link Count:         1

*  Size:               147451414

*  Mode:               0100700

*  Flags:              0x110000e0

*  SmartLinked:        False

*  Physical Blocks:    18019

However, when running the ‘isi get’ CLI command on the same file within the writable snapshot tree (/ifs/test/wsnap1/testfile1), the writable, space-efficient copy now only consumes five physical blocks, as compared with 18019 blocks in the original file:

# isi get -D /ifs/test/wsnap1/testfile1.zip

POLICY   W   LEVEL PERFORMANCE COAL  ENCODING      FILE              IADDRS

default      16+2/2 concurrency on    UTF-8         testfile1.txt        <1,9,92028928:8192>

*************************************************

* IFS inode: [ 1,9,1054720:512 ]

*************************************************

*

*  Inode Version:      8

*  Dir Version:        2

*  Inode Revision:     145

*  Inode Mirror Count: 1

*  Recovered Flag:     0

*  Restripe State:     0

*  Link Count:         1

*  Size:               147451414

*  Mode:               0100700

*  Flags:              0x110000e0

*  SmartLinked:        False

*  Physical Blocks:    5

In OneFS 9.12, writable snapshots are able to inherit some time related attributes from the source snapshot. With OneFS 9.11 and earlier, the implementation of writable snapshots was to have these attributes be created on the writable snapshot. But with this behavior change (and via the sysctl ‘copy time attributes w snap core’), OneFS now inherits these time-based attributes from the source snapshots. This means that creation, modification, and access time will be inherited the first time the writable snapshot file is accessed, and modified as and when the writable snapshot is accessed or changed.

More information about OneFS commands and feature configuration is available in the OneFS Administration Guide.

Writable snapshots use the OneFS policy domain manager, or PDM, for domain membership checking and verification. For each writable snapshot, a ‘WSnap’ domain is created on the target directory. The ‘isi_pdm’ CLI utility can be used to report on the writable snapshot domain for a particular directory.

# isi_pdm -v domains list --patron Wsnap /ifs/test/wsnap1

Domain          Patron          Path

b.0700          WSnap           /ifs/test/wsnap1

Other details of the backing domain can also be displayed with the following CLI syntax:

# isi_pdm -v domains read b.0700

('b.0700',):

{ version=1 state=ACTIVE ro store=(type=RO SNAPSHOT, ros_snapid=650, ros_root=5:23ec:0011)ros_lockid=1) }

Domain association does have some ramifications for writable snapshots in OneFS 9.3  and later, and there are a couple of notable caveats. For example, files within the writable snapshot domain cannot be renamed outside of the writable snapshot to allow the file system to track files in a simple manner.

# mv /ifs/test/wsnap1/file1 /ifs/test

mv: rename file1 to /ifs/test/file1: Operation not permitted

The nesting of writable snapshots is not permitted in OneFS 9.3 and later releases. An attempt to create a writable snapshot on a subdirectory under an existing writable snapshot will fail with the following CLI command warning output:

# isi snapshot writable create prod1 /ifs/test/wsnap1/wsnap1-2

Writable snapshot:/ifs/test/wsnap1 nested below another writable snapshot: Operation not supported

When a writable snapshot is created, any existing hard links and symbolic links (symlinks) that reference files within the snapshot’s namespace will continue to work as expected. However, existing hard links with a file external to the snapshot’s domain will disappear from the writable snapshot, including the link count. 

Be aware that any attempt to create a hard link to another file outside of the writable snapshot boundary will fail.

# ln /ifs/test/file1 /ifs/test/wsnap1/file1

ln: /ifs/test/wsnap1/file1: Operation not permitted

However, symbolic links will work as expected. OneFS hard-link and symbolic-link actions and expectations regarding writable snapshots are illustrated in the following diagram:

Figure 5.   Writable snapshots, hard links, and symbolic links

While the writable snapshots feature does not have its own specific license, its use is governed by the OneFS SnapshotIQ data service. As such, in addition to a general OneFS license, SnapshotIQ must be licensed across all the nodes in order to use writable snapshots on a PowerScale cluster running OneFS 9.3 or later. Also, the ‘ISI_PRIV_SNAPSHOT’ role-based administration privilege is required on any cluster administration account that will create and manage writable snapshots. For example:

# isi auth roles view SystemAdmin | grep -i snap

             ID: ISI_PRIV_SNAPSHOT

More information about OneFS roles-based administration and access control is available in the document Access Control Lists on Dell PowerScale OneFS.

In general, writable snapshots file access is marginally less performant compared to the source files, or head files, since an additional level of indirection is required to access the data blocks. This case is true for older source snapshots, where a lengthy read-chain can require considerable ‘ditto’ block resolution. This result occurs when parts a file no longer resides in the source snapshot, and the block tree of the inode on the snapshot does not point to a real data block. Instead it has a flag marking it as a ‘ditto block’. A ditto block indicates that the data is the same as the next newer version of the file. Therefore, OneFS automatically looks ahead to find the more recent version of the block. If there are large numbers (such as hundreds or thousands) of snapshots of the same unchanged file, reading from the oldest snapshot can have a considerable impact on latency.

Writable snapshots in OneFS 9.3 and later releases co-exist with most other OneFS data services, although there are several caveats to bear in mind. The following table describes the integration, influence, and compatibility between writable snapshots and the various OneFS data services.

Table 1.      OneFS writable snapshots and data services integration

Note: Most of the abovementioned services each require a product license or specific hardware. Licensed data services are not enabled, configured, and activated by default on a cluster.

A common use case for writable snapshots is in disaster recovery testing. For DR purposes, an enterprise typically has two PowerScale clusters configured in a source/target SyncIQ replication relationship. Many organizations have a requirement to conduct periodic DR tests to verify the functionality of their processes and tools in the event of a business continuity interruption or disaster recovery event.

Figure 6.   Writable snapshots and SyncIQ DR test workflow

Given the writable snapshots compatibility with SyncIQ caveats described in the previous table, a writable snapshot of a production dataset replicated to a target DR cluster can be created as follows:

1. On the source cluster, create a SyncIQ policy to replicate the source directory (/ifs/test/head) to the target cluster:

# isi sync policies create --name=ro-head sync --source-rootpath=/ifs/prod/head --target-host=10.224.127.5 --targetpath=/ifs/test/ro-head

# isi sync policies list

Name  Path              Action  Enabled  Target

---------------------------------------------------

ro-head /ifs/prod/head  sync    Yes      10.224.127.5

---------------------------------------------------

Total: 1

2. Run the SyncIQ policy to replicate the source directory to /ifs/test/ro-head on the target cluster:

# isi sync jobs start ro-head --source-snapshot s14

# isi sync jobs list

Policy Name  ID   State   Action  Duration

-------------------------------------------

ro-head        1    running run     22s

-------------------------------------------

Total: 1

# isi sync jobs view ro-head

Policy Name: ro-head

         ID: 1

      State: running

     Action: run

   Duration: 47s

 Start Time: 2021-06-22T20:30:53

Target:

3. Take a read-only snapshot of the replicated dataset on the target cluster:

# isi snapshot snapshots create /ifs/test/ro-head

# isi snapshot snapshots list

ID   Name                                        Path

-----------------------------------------------------------------

2    SIQ_HAL_ro-head_2021-07-22_20-23-initial /ifs/test/ro-head

3    SIQ_HAL_ro-head                          /ifs/test/ro-head

5    SIQ_HAL_ro-head_2021-07-22_20-25         /ifs/test/ro-head

8    SIQ-Failover-ro-head-2021-07-22_20-26-17 /ifs/test/ro-head

9    s106976           /ifs/test/ro-head

-----------------------------------------------------------------

4. Using the (non SIQ_*) snapshot of the replicated dataset above as the source, create a writable snapshot on the target cluster at /ifs/test/head:

# isi snapshot writable create s106976 /ifs/test/head

5. Confirm the writable snapshot has been created on the target cluster:

# isi snapshot writable list

Path              Src Path         Src Snapshot

----------------------------------------------------------------------

/ifs/test/head  /ifs/test/ro-head  s106976

----------------------------------------------------------------------

Total: 1

# du -sh /ifs/test/ro-head

 21M    /ifs/test/ro-head

6. Export or share the writable snapshot data under /ifs/test/head on the target cluster using the protocol or protocols of choice. Mount the export or share on the client systems and perform DR testing and verification as appropriate.
7. When DR testing is complete, delete the writable snapshot on the target cluster:

# isi snapshot writable delete /ifs/test/head

Writable snapshots cannot be refreshed from a newer read-only source snapshot. A new writable snapshot would need to be created using the newer snapshot source in order to reflect and subsequent updates to the production dataset on the target cluster.

More information about OneFS SyncIQ replication configuration and management is available in the SyncIQ best practices guide.

OneFS writable snapshots are used to create and manage space-efficient copies of production environments, which can be beneficial for the following workflow scenarios:

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.

OneFS writable snapshots, on top of the industry’s leading scale-out NAS architecture, deliver on the promise for the evolving needs of surveillance, scientific, media, backup applications, and other workloads. OneFS meets these needs without sacrificing the ease of management, performance, scalability, and protection that OneFS affords.

Dell PowerScale clusters provide a scalable, multi-protocol solution, which is further evidence of the Dell commitment to developing the next generation of data management products and solutions for the enterprise.

The Dell Technologies Info Hub provides expertise to ensure customer success with Dell storage and data protection products. 

Dell.com/support is focused on meeting customer needs with proven services and support.