The IBM Spectrum Scale supports the file access protocols such as NFS (NFSv3 and NFSv4) and SMB (SMB 3.0). The IBM Spectrum Scale system can be configured to store and access data through NFS and SMB protocols. Based on the customer’s business requirements, the business data at times need to adhere various compliances like Health Insurance Portability and Accountability Act (HIPAA), Federal Financial Institutions Examination Council (FFIEC). A subset of these compliance policies mandate protection of the files or data from tampering, malicious data insertion, and deletion. This subset is also known as WORM (Write Once Read Many) functionality. Spectrum scale provides WORM functionality via its “immutability” feature.
Once marked immutable, the file cannot be modified or deleted by any type of users, including the root user. Immutability is required when files stored on a file system contain important or confidential data that needs to be secured from deletion either for a specific time frame or indefinitely, and also from erroneous data insertion by the users.

The IBM Spectrum Scale supports the following two different approaches to achieve immutability.

  • Define immutability directly at the file level. To define immutability for a file, use the “mmchattr” command from the cluster node. The downside of this approach is that the business application must be running on cluster node with root privileges (As a reference read article on Immutability and appendOnly features in GPFS 3.4v on AIX)
  • Define immutability at the fileset level, by setting its IAM mode (IAM – Integrated Archive Manager). Use the business application to set the required retention period through “touch” and “chmod” commands. This operation can be performed from a non-cluster node over NFS/SMB protocol. It is recommended to follow this approach to set immutability for files. As this approach is more practical and flexible, this article discusses only about defining immutability at the fileset level.


  • A typical setup of spectrum Scale:

    Export creation on Spectrum Scale
    To access the data over NFS/SMB client, one needs to create an export on Spectrum Scale. For achieving the goal of WORM like functionality using IAM mode of fileset, the export creation should follow below steps.
    Note: It is assumed that reader knows how to enable protocol support on your Spectrum Scale deployment.

      Step 1: Create a fileset

    First create a fileset using “mmcrfileset” command as shown below.
    # mmcrfileset gpfs0 immfset
    Fileset immfset created with id 2 root inode 17052.
    # mmlinkfileset gpfs0 immfset -J /ibm/gpfs0/immfset
    Fileset immfset linked at /ibm/gpfs0/immfset

      Step 2: Choose the IAM mode for the created fileset

    Set the immutability for the fileset by specifying values for the —iam-mode parameter of the mmchfileset command. IBM Spectrum Scale supports four levels of compliance modes. One need to choose as per the requirements. This article makes use of “Compliant” mode. (Read more details on IAM mode.)
    # mmchfileset gpfs0 immfset --iam-mode co
    Fileset immfset changed.
    # mmlsfileset gpfs0 -m
    Filesets in file system 'gpfs0':
    Name Status Path IAM mode
    root Linked /ibm/gpfs0 off
    immfset Linked /ibm/gpfs0/immfset compliant

    Properties of “compliant” IAM mode
    • Hardlink is not allowed
    • Immutable files cannot be edited, appended, or deleted before completion of retention period
    • Immutable files cannot be changed to mutable
    • Expiration time can NOT be set backwards (cannot reduce retention period)

      Step3: Create CES export

    Create an export over the fileset by using commands “mmnfs export add” and “mmsmb export add” commands as shown in the following example.
    # mmnfs export add /ibm/gpfs0/immfset --client \*\(ACCESS_TYPE=RW,SQUASH=no_root_squash\)
    9.X.X.X: Redirecting to /bin/systemctl stop nfs-ganesha.service
    9.X.X.X: Redirecting to /bin/systemctl stop nfs-ganesha.service
    9.X.X.X: Redirecting to /bin/systemctl start nfs-ganesha.service
    9.X.X.X: Redirecting to /bin/systemctl start nfs-ganesha.service

    # mmnfs export list
    Path Delegations Clients
    -------------------------------------------
    /ibm/gpfs0/immfset none *

    # mmsmb export add immshare /ibm/gpfs0/immfset
    mmsmb export add: The SMB export was created successfully.

    # mmsmb export list
    export path guest ok smb encrypt
    immshare /ibm/gpfs0/immfset no auto
    Warning:
    Unused options suppressed in display:
    "browseable"

    Making the file immutable from NFS/SMB client
    Now the business application (which need to adhere to compliance policies) would need some extra work to make the required files immutable. Here it is assumed that the export from Spectrum Scale has been mounted on the client system and business application has required access to the exported data.

    Making a file immutable is 2 step process: first set the “atime” in the future (expiration time), such a way that time difference between current time and the future time will be the required retention period, and the second step is to make the file read-only. As we are talking about data access over NFS and CIFS, we have different methods.

    Operation from NFS client
    To make a file immutable using NFS client, the NFS export must be mounted, and the user must be working in the directory to which the immutable file set is linked. Perform the following steps to make a file immutable using NFS client:

  • Use the touch command to change the access time.
    For example:
    $ touch -t 201601071010.10 file1
  • Use the chmod command to make the file read-only.
    For example:
    $ chmod 400 file1
  • Operations from SMB client
    To make a file immutable using SMB client, the SMB export must be mapped or mounted, and the user must be working in the directory to which the immutable file set is linked. Perform the following steps to make a file immutable using SMB client:
    1. Use the Touch Utility or Windows power shell as shown in the following example to change the access time:

    2. Make the file read-only as shown in the following figure:

    Limitations
    While working from SMB client, some of the operations are not allowed. These limitations are mostly due to Windows behavior. Following are the SMB client limitations:
    • After passing the expiration time, the file cannot be deleted through a SMB client. Users with required access privileges can delete such files from the cluster node. Alternately, if the same path is available on the NFS client, then a user can delete the file from the NFS client.
    • Unable to change the retention time in future. So once retention time set, that cannot be changed.

    Things to remember
    Do remember the following while using the immutability feature:
    • From the NFS/SMB client immutability can be set only at the file level and cannot be set for a directory. To set immutability for a directory, one has to be on spectrum scale cluster node, the directory needs to be in regular fileset (not IAM enabled) and need to make use of “mmchattr –i yes” command.
    • Asynchronous replication does not work if the file is made immutable on the target site. In such cases, the changes made to the source file will not get updated at the target site.
    • The immutable files cannot be configured for HSM functionality.
    • In remote caching setup, home and cache sites cannot have immutable files, if that site is supposed to receive the updated data from other sites.

    Join The Discussion

    Your email address will not be published. Required fields are marked *