Large Directories

Since a writable snapshot performs a copy-on-read to populate file metadata on first access, the initial access of a large directory (containing millions of files, for example) that tries to enumerate its contents will be relatively slow because the writable snapshot has to iteratively populate the metadata. This scenario is applicable to namespace discovery operations such as ‘find’ and ‘ls’, unlinks and renames, plus other operations working on large directories. However, any subsequent access of the directory or its contents will be fast since file metadata will already be present and there will be no copy-on-read overhead.

The unlink_copy_batch and readdir_copy_batch parameters under the sysctl ‘efs.wsnap’ control of the size of batch metadata copy operations. These parameters can be helpful for tuning the number of iterative metadata copy-on-reads for datasets containing large directories. However, these sysctls should only be modified under the direct supervision of Dell technical support.

Writable snapshot metadata read/write

Initial read and write operations will perform a copy-on-read and will therefore be marginally slower compared to the head. However, once the copy-on-read has been performed for the LINs, the performance of read/write operations will be nearly equivalent to head.

Writable snapshot data read/write

In general, writable snapshot data reads and writes will be slightly slower compared to head.

Multiple writable snapshots of single source

The performance of each subsequent writable snapshot created from the same source read-only snapshot will be the same as that of the first, up to the default recommended limit of 30 writable snapshots. This is governed by the ‘max_active_wsnpas’ sysctl.

# sysctl efs.wsnap.max_active_wsnaps

efs.wsnap.max_active_wsnaps: 30

The ‘max_active_wsnaps’ sysctl can be configured up to a maximum of 2048 writable snapshots per cluster. However, changing this sysctl from its default value of 30 is discouraged in OneFS 9.3 and later.

Writable snapshots and SmartPools tiering

Unmodified file data in a writable snapshot is read directly from the source snapshot. If the source is stored on a lower performance tier than the writable snapshot’s directory structure, this placement will negatively impact the writable snapshot’s latency.

Storage Impact

The storage capacity consumption of a writable snapshot is proportional to the number of writes, truncate, or similar operations it receives. This result occurs because only the changed blocks relative to its source snapshot are stored. The metadata overhead will grow linearly as a result of copy-on-reads with each new writable snapshot that is created and accessed.

Snapshot Deletes

Writable snapshot deletes are de-staged and performed out of band by the TreeDelete job. As such, the performance impact should be minimal, although the actual delete of the data is not instantaneous. Also, the TreeDelete job has a path to avoid copy-on-writing any files within a writable snapshot that have yet to have been enumerated.