Limitations of unified file and object access

The following limitations apply for unified file and object access in IBM Spectrum Scale™.

• Existing file data cannot be enabled for object access. The base container must be created from the object interface in the fileset being used for the unified access storage policy and then only the data added after that is enabled for object access.

• Concurrent access to the same object or file from file and object interface at the same time will lead to an undefined state. There are a variety of ways to prevent conflicts. For example:

  1. You can have your workflow enforce this.
  2. You can explicitly enforce read-only access for some periods. With NFS and SMB, it can be done in the export definition. With POSIX, it can be done using ACLs.

• Files or directories created at the base container level cannot be enabled for object access. Only the files created under the container are enabled for object access.

• Multi-region object deployment cannot be used with unified file and object access.

• Object versioning is not supported with unified file and object access.

• Special files such as device files and pipes, and soft links can exist in the object container directory, but they are not visible from the object interface.

• AFM-based Async DR is supported with unified file and object access. No other active file management (AFM) modes are supported with unified file and object access.

• Containers must be deleted from the object interface. Container directories deleted from the file interface continue to show up in the container listing, until the container is deleted from the object interface.

• GPFS™ quota and Swift container and account quota are mutually exclusive in Release 4.2 and later. The user quota assigned to a user or a group in GPFS does not relate to the container quota defined in the object interface.

• Swift large object support (dynamic large object and static large object) is not available with unified file and object-enabled containers. S3 multipart uploads are also not supported with unified file and object-enabled containers.

• GPFS immutability is not supported with unified file and object access.

• Only object metadata can be viewed and modified from the object interface. Extended attributes defined from the file interface cannot be viewed from the object interface.

• Empty directories created from the file interface within a container are not objectized and they are not listed in the container listing.

• Files or directories with "::" or newline characters in their names are not supported and these files or data residing in these containers are not objectized.

• Change of authentication scheme of file or object could directly impact access to existing file or object data. Therefore, change of authentication is not supported as it results in loss of access for the users to the existing data on the system.

• Object ETag is inaccurate in the following scenarios:

  • Whenever an object is modified from the file interface. In this case, performing a conditional request using 'If-Match' or 'If-None-Match' headers returns incorrect results.
  • ETag for files on an explicit GET request when the size of the object has changed (increased or decreased).
  • ETag for files on an explicit GET request when the content of the object has changed but the size has remained the same.
  • If the user.swift.metadata extended attribute is explicitly deleted form the file interface, ETag is not present because of which the headers do not return correct results. Users need to wait for at least one cycle of objectization or they need to explicitly objectize that file to use the ETag conditional request feature.