Starting with PowerStoreOS 3.0, File-Level Retention (FLR) is available. FLR is a feature that is used to protect file data from deletion or modification until a specified retention date. This functionality is also known as Write-Once, Read-Many (WORM).

FLR modes

PowerStore supports FLR-Enterprise (FLR-E) and FLR-Compliance (FLR-C). FLR-C has additional restrictions and is designed for companies that need to comply with federal regulations. Table 14 shows a comparison of FLR-E and FLR-C.

Table 14.  FLR-E and FLR-C

FLR-C includes a data integrity check, as required by SEC rule 17a-4(f). When data is written, it is read back by the storage system to ensure that it has not changed during the write process. If the data does not match, the comparison is retried two more times. If there is still a mismatch, an error is reported. Files that are already locked do not have any additional write verification because they cannot be written to anymore. The write verification functionality is disabled by default because the additional overhead can have a performance impact. However, enable write verification if it is required for compliance reasons. It can be enabled by changing the NAS server parameter FLRCompliance.writeverify from 0 to 1.

The FLR mode is set when a general file system is created and cannot be changed afterwards. FLR is not available on VMware file systems because file locking is not necessary for NFS datastores. The available FLR modes are Off (default), Enterprise, and Compliance.

Retention settings

If FLR is enabled, the following retention periods can be configured:

• Minimum—Specifies the shortest period for which files can be locked
• Default—Used when a file is locked, and a retention period is not specified
• Maximum—Specifies the longest period that files can be locked

The minimum, maximum, and default retention periods can be changed afterwards but any updates do not apply to any files that are already locked. Figure 45 shows the FLR step of the file system provisioning wizard.

Figure 45.    File Level Retention configuration

FLR also has integrated Auto-Lock and Auto-Delete functionality that can optionally be enabled for automation purposes. These settings can be configured on an FLR-enabled file system after it is provisioned, as shown in Figure 46. They are both disabled by default and can be modified at any time.

Figure 46.    File Level Retention properties

• Auto-Lock—Files are automatically locked if they are not modified for a user-specified period (Policy Interval)

• Automatically locked files use the default retention period
• Files in append-only mode are also subject to automatic locking

• Policy Interval—Specifies how long to wait after files are modified before they are automatically locked

• Specifies how long to wait after files are modified before they are automatically locked
• Default: 1 Hour; Minimum: 1 Minute, Maximum, 365 Days

• Auto-Delete—Automatically deletes locked files after their retention date has expired

• Weekly process that scans the file system to search for expired files
• The first scan is initiated seven days after the feature is enabled

FLR file states

In an FLR-enabled file system, files can be in one of four states:

• Not locked

• Initial state of a new file
• Treated in the same manner as a file in a non-FLR file system (can be modified, deleted, renamed, moved, and so on)

• Locked

• Cannot be modified or deleted until the retention date has passed
• Files can be manually locked by a user or automatically locked by the system or FLR Toolkit
• A locked file can have its retention period extended, but not shortened

• Append only

• Existing data cannot be modified or deleted
• New data can be added to the end of the file
• Useful for log files
• Can be locked later

• Expired

• File that was previously locked, but the retention date has passed
• An expired file can only be relocked or deleted from the file system; it cannot be changed to append-only (unless it is empty)
• Data in expired files cannot be modified

Locking files on Linux

The process to set a retention date and lock a file depends on the client operating system. Linux natively includes commands to perform these operations.

• Users can set the retention period using the touch command to set the last access time of the file to a future date and time

• root@vm:~# touch -at 202201141200 FLRtest01.txt

• Users can lock the file by changing the access permissions to read-only using the chmod command

• root@vm:~# chmod -w FLRtest01.txt

Locking files on Windows

Windows does not offer a native UI or CLI option and requires using the Windows API SetFileTime function instead. The Dell FLR Toolkit is a Windows application that presents the SetFileTime function in a user-friendly manner, enabling administrators to manage files on an FLR-enabled file system.

The FLR Toolkit includes the following user interfaces and tools:

• FLR Explorer—GUI that can be used to set retention periods, lock files, run queries, and generate reports
• FLRApply—CLI options for setting retention periods and locking files
• FLR Monitor Service—Service that monitors folders in FLR-enabled file systems and acts on them, based on a user-configured policy
• Windows Explorer Enhancements—Adds FLR options to the Windows Explorer right-click and Properties menus

To set up the FLR Toolkit, enable the Distributed Hierarchical Storage Management (DHSM) API on the NAS server, specify the credentials that the toolkit will use, and install the toolkit on a Windows client.

Creating append-only files

To create an append-only file, create an empty file, remove write permissions, and then reapply write permissions to the file. To later lock an append-only file, set the retention date and remove write permissions again. You can make these changes with native Linux commands or by using the FLR Toolkit.

FLR interoperability

Operations such as thin clones and replication on an FLR-enabled file system maintain the same FLR mode. For example, if the source file system has FLR-E enabled, the clone or replication destination file system also has FLR-E enabled, and this cannot be changed.

FLR activity log

When an FLR-enabled file system is created, an FLR_Logs directory is automatically created on the root of the file system to store all FLR-related activity. This activity includes operations such as files getting locked successfully, attempted changes to locked files, and retention settings updates. Individual details of each event, such as the user, timestamp, file information, and results, are also included. Files in the activity log are identified by their inode number.

The log itself is an append-only file. When the size reaches 10 MB, it is locked with the maximum retention period, and a new log is created. The following is an example of the FLR activity log:

root@vm:~# cd /mnt/FLR_Logs/

root@vm:/mnt/FLR_Logs/# ls

flrLog20220126193040

root@vm:/mnt/FLR_Logs/# cat flrLog20220126193040

Wed Jan 26 19:30:40 2022 : Activity log file created

Wed Jan 26 19:30:40 2022 : Initial fs rp range: max = infinite, default = 1D, min = 0D

Wed Jan 26 19:36:27 2022 : Set auto lock feature: oldVal = disable : newVal = enable : Passed

Wed Jan 26 19:36:27 2022 : Set auto lock policy Interval: oldVal = 3600 : newVal = 60 : Passed

Wed Jan 26 19:40:58 2022 : Worm commit clean file : Inode No = 9459 : Generation No = 1643225480 : Uid = 0 : Gid = 1 : FileMode = 444 : FileSize = 14 : RP = Thu Jan 27 19:40:58 2022 : Passed