Originally posted by: Nils Haustein

I would like to share some of my experiences with the new immutability mode for filesets in Spectrum Scale. This was introduced with the IBM Spectrum Scale™ (GPFS) release 4.1.1 in June 2015 [1]. The most amazing observation is that you can set files to WORM mode (write once read many) using the same set of commands as with NetApp® SnapLock® [2]. This works best in the GPFS file system, but it could also be used via NFS or SMB (some limitations may apply).

I would like to thank my dear friend Nick Cvetkovic for the thorough review.

Introduction to GPFS immutability function

In this context immutability means to associate a file with a retention time and make the file write-once-read-many protected (WORM) so it cannot be deleted or changed during the retention time. After the retention time has expired the file can be deleted but not changed.

With GPFS 3.4 the extended attributes “immutable” and “append-only” were added to GPFS files and directories [1]. These attributes can be set by a file owner using the command “mmchattr”. An immutable file cannot be changed, renamed or deleted. An append-only file allows append operations, but no other modifications, renames or deletes. GPFS allow setting these attributes on any file or directory. The downside is that these attributes can be reset. In addition there is no concept of a retention time.

With IBM Spectrum Scale™, alias GPFS 4.1.1, the immutability function has been extended to GPFS filesets. A GPFS fileset can be configured with an integrated archive manager (IAM) mode using the command “mmchfileset”. Files stored in such an immutable fileset can have their immutability and append-only set using standard POSIX commands. The semantic is similar to the SnapLock® mode where files can be set to immutable by removing write permissions (chmod command) and retention times can be assigned by setting the “last access date” of the file (touch command). These commands will cause the extended attributes “immutable” and “append-only” to be set automatically. These attributes cannot be reset. In addition there is the concept of retention time.

GPFS fileset IAM modes

A GPFS fileset can be considered a logical partition within a GPFS file system allowing certain operations independent of the rest of the file system. From a user perspective a fileset is a directory in the file system. Functions available on a fileset level include setting quota, taking snapshot*, AFM caching* and IAM mode.
* Only for independent filesets

The IAM mode makes the fileset immutable. It can be set using the “mmchfileset” command with the parameter –iam-mode. A GPFS fileset can be set to one of the four IAM modes:

• none: No immutability mode is set (default), the fileset behaves like a regular fileset
• advisory (ad): Allows setting retention times and WORM protection, but files can be deleted with the proper file permission, whatsoever.
• noncompliant (nc): Advisory mode plus files cannot be deleted if retention time has not expired. However retention times can be reset and files can be deleted but not changed.
• compliant (co): Noncompliant mode and retention time cannot be reset. When retention time has expired files can be deleted but not changed.

The fileset IAM modes can be upgraded (from advisory to compliant), but not downgraded.

It is possible to created nested filesets whereby one fileset is within the other fileset. The IAM mode is not inherited. This means when fileset1 is configured in compliant mode and fileset2 within fileset1 is a regular fileset, then files stored in fileset2 cannot be managed in a compliant manner. As with many things, you have to know what you do and having a regular fileset within a compliant fileset does not make sense to me.

Differences and limitations

The attributes “immutable” and “append-only” can be set for files in a regular fileset and for files in an immutable fileset. The table below describes the key differences:

* assume immutable fileset in IAM mode compliant

Most of the file system commands in an immutable fileset have the same effect as with NetApp® SnapLock®. One of the key differences from SnapLock is the concept of immutable directories. With SnapLock directories can be set to immutable which applies limitations to file operations within this directory. GPFS immutable fileset do not have the notion of immutable directories. I have not seen a use case for immutable directories either (see more information in section Working with directories).

An immutable filesets can also be exported via NFS or SMB. Some of the limitations are:

• It is not possible to set and manage append-only mode via NF
• Setting retention times (last access time) via CIFS may not work
• Setting a file or directory as immutable or append-only is not allowed for AFM SW/IW/RO/LU and AFM primary/secondary filesets

Working with immutable files

In the following section I will demonstrate how to work with immutable and append-only files using simple examples. Some basic commands first.

Setting a file immutable can be done with standard UNIX command or GPFS commands and involves two steps:

• setting the retention time
• setting the file to immutable

The retention time can be set and extended using one or both of the following methods:

• using standard Unix “touch” command whereby the retention time is interpreted as the last access time: touch –at MMDDhhmmss filename
• using the GPFS command “mmchattr” and setting the retention time directly in GPFS: mmchattr –E YYYY-MM@DD:hh:mm:ss filename

Accordingly the file can be set to immutable with either of these two methods:

• Unix command: chmod –w filename
• GPFS command: mmchattr –i yes

To set append only mode on an empty file use one of these methods:

• Unix command: chmod –w filename; chmod +w filename
• GPFS command: mmchattr –a yes

The UNIX commands also work on a NFS export.

In the subsequent examples I will use UNIX commands to manage immutable and append-only files.

Creating immutable files

In order to create an immutable fileset, create and link a regular fileset (dependent or independent) using the mmcrfileset and mmlinkfileset commands. To assign the compliant IAM mode use the command:

mmchfileset <filesystem> <fileset> --iam-mode compliant

To list the IAM mode of a fileset use the following command:

mmlsfileset <filesystem> <fileset> --iam-mode

Change to the fileset directory to manage immutable files.

First create files with read-write permissions and fill the file with content:

# echo “Hello World” > file

Check the GPFS extended attributes of the file which indicate that the file is not immutable:

#mmlsattr -L file

file name:            file

metadata replication: 1 max 2

data replication:     1 max 2

immutable:            no

appendOnly:           no

indefiniteRetention:  no

flags:

storage pool name:    system

fileset name:         WORM

snapshot name:

creation time:        Tue Jun 10 21:18:58 2014

Windows attributes:   ARCHIVE

Set a future time stamp to the file, in this case 1. July:

#touch -at 07010000 file

Set the file to read-only:

#chmod –w file

Now the attributes show that immutability is set and also show the previously set expiration time:

#mmlsattr -L file

file name:            file

metadata replication: 1 max 2

data replication:     1 max 2

immutable:            yes

appendOnly:           no

indefiniteRetention:  no

expiration Time:      Tue Jul  1 00:00:00 2014

flags:

storage pool name:    system

fileset name:         WORM

snapshot name:

creation time:        Tue Jun 10 21:18:58 2014

Windows attributes:   ARCHIVE READONLY

Trying to delete the file if the fileset is in compliant mode will fail (it will work in Advisory mode, see section GPFS fileset IAM modes).

# rm -f file

rm: cannot remove `file': Read-only file system

Trying to reset the retention time will fail if the immutability mode is compliant:

# touch -at 06110000 file

touch: cannot touch `file': Read-only file system

Setting the retention time to a future date- works:

#touch -at 07020000 file

#mmlsattr -L file

file name:            file

metadata replication: 1 max 2

data replication:     1 max 2

immutable:            yes

appendOnly:           no

indefiniteRetention:  no

expiration Time:      Wed Jul  2 00:00:00 2014

flags:

storage pool name:    system

fileset name:         WORM

snapshot name:

creation time:        Tue Jun 10 21:18:58 2014

Windows attributes:   ARCHIVE READONLY

Resetting the attribute “immutable” does not work if the IAM mode is advisory or higher:

# mmchattr -i no file

file: change immutable, flags failed: Operation not permitted.

Can not set immutable or appendOnly flag to No and indefiniteRetention flag to Unchanged, Permission denied!

Trying to append or overwrite the file does not work:

# echo "hello world" > file

bash: file: Read-only file system

# echo "hello world" >> file

bash: file: Read-only file system

Note, these operations can also be done on NFS export that is exporting the fileset.

Working in Append mode

I did some further testing with append mode. Empty files can be set to append mode by setting the file to read-only and subsequently setting the empty file to read-write again. In append mode the file can be appended to but not overwritten. To end append mode (file is full) set the file to read-only again.

First create an empty file:

# touch file1

Set retention to a future date via the last access date:

# touch -at 06110000 file1

Now set the file to read-only and check the attributes. The immutability attribute will be set.

# chmod -w file1

# mmlsattr -L file1

file name:            file1

metadata replication: 1 max 2

data replication:     1 max 2

immutable:            yes

appendOnly:           no

indefiniteRetention:  no

expiration Time:      Wed Jun 11 00:00:00 2014

flags:

storage pool name:    system

fileset name:         WORM

snapshot name:

creation time:        Tue Jun 10 22:11:11 2014

Windows attributes:   ARCHIVE READONLY

Set the file to read-write again. This will only work once on an empty file. The attribute changed to appendOnly:

# chmod +w file1

# mmlsattr -L file1

file name:            file1

metadata replication: 1 max 2

data replication:     1 max 2

immutable:            no

appendOnly:           yes

indefiniteRetention:  no

expiration Time:      Wed Jun 11 00:00:00 2014

flags:

storage pool name:    system

fileset name:         WORM

snapshot name:

creation time:        Tue Jun 10 22:11:11 2014

Windows attributes:   ARCHIVE

File cannot be deleted or overwritten:

# rm -f file1

rm: cannot remove `file1': Read-only file system

# echo "hello world" > file1

bash: file1: Read-only file system

Appending to the file works:

# echo "hello world" >> file1

To make the file immutable again set it to read-only. The GPFS attributes show immutable but no longer appendOnly:

# chmod -w file1

# mmlsattr -L file1

file name:            file1

metadata replication: 1 max 2

data replication:     1 max 2

immutable:            yes

appendOnly:           no

indefiniteRetention:  no

expiration Time:      Wed Jun 11 00:00:00 2014

flags:

storage pool name:    system

fileset name:         WORM

snapshot name:

creation time:        Tue Jun 10 22:11:11 2014

Windows attributes:   ARCHIVE READONLY

Retention time can be changed depending on  the immutability mode. Setting the expiration time forward works:

# touch -at 06130000 file1

# mmlsattr -L file1

file name:            file1

metadata replication: 1 max 2

data replication:     1 max 2

immutable:            yes

appendOnly:           no

indefiniteRetention:  no

expiration Time:      Fri Jun 13 00:00:00 2014

flags:

storage pool name:    system

fileset name:         WORM

snapshot name:

creation time:        Tue Jun 10 22:11:11 2014

Windows attributes:   ARCHIVE READONLY

Resetting retention time does not work on a compliant fileset.

# touch -at 06120000 file1

touch: cannot touch `file1': Read-only file system

In immutable mode file cannot be overwritten or appended:

# echo "hello world" > file1

bash: file1: Read-only file system

# echo "hello world" >> file1

bash: file1: Read-only file system

Working with directories

There is not really a concept of making directories within an immutable fileset immutable, this happens automatically. A directory within an immutable fileset does not allow setting the extended attributes “immutable” or “append-only” whatsoever. However, a directory within an immutable becomes immutable as soon as files within this directory are set to immutable.  This means the directory cannot be renamed or deleted once immutable files have been stored within this directory.

This differs a bit from the SnapLock® mode where even empty directories can be set to immutable.  But what is the purpose of setting empty directories to immutable? I have no idea.

Summary

The new immutability function based on immutable filesets is a good foundation for supporting SnapLock® like functions within GPFS. I’m really looking forward using an immutable fileset as WORM storage for SSAM (System Storage Archive Manager) J.

I heard rumors IBM is planning to certify this function by an external auditor. This is not guaranteed, however it would be great because many use cases for compliance require an independent compliance assessment.

References

[1] Immutability and append only:

http://www-01.ibm.com/support/knowledgecenter/STXKQY_4.1.1/com.ibm.spectrum.scale.v4r11.adv.doc/bl1adv_integratedarchiveplatform.htm?lang=en

[2] Information about NetApp® SnapLock®

http://www.netapp.com/uk/products/protection-software/snaplock.aspx

Disclaimer

NetApp® is a registered trade mark of NetApp Corporation in the United States and other countries.

SnapLock® is a registered trade mark of NetApp Corporation in the United States and other countries.