Limitations of unified file and object access

Read about the limitations to unified file and object access in IBM Storage Scale.

The following limitations apply:

  • The base container must be created from the object interface in the fileset that is being used for the unified access storage policy. Then, only the files that are added after that are enabled for object access.

  • Concurrent access to the same object or file from file and object interface at the same time leads to an undefined state. You can prevent conflicts:
    1. You can have your workflow enforce the limitation.
    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 by using ACLs.

  • Files or directories that are created at the base container level cannot be enabled for object access. Only the files that are 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 by unified file and object access.

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

  • Containers must be deleted from the object interface. Container directories that are deleted from the file interface continue to show that 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 IBM Storage Scale 4.2 and later. The user quota that is 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 by unified file and object-enabled containers.

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

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

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

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

  • Change of authentication scheme of file or object might 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.
    • If the user.swift.metadata extended attribute is explicitly deleted from the file interface, ETag is not present because of which the headers do not return correct results. You must wait for at least one cycle of objectization or explicitly objectize that file to use the ETag conditional request feature.
    Note: An incorrect ETag is corrected when a GET or HEAD request is done on the object.
  • The IBM Storage Scale ILM policy rules work with file-extended attributes, and rules can be easily created based on extended attributes and their values. However, these rules do not work directly over Swift user-defined metadata. All of Swift user-defined metadata is stored in a single extended attribute in the IBM Storage Scale file system. To create ILM rules, the format and sequence in which the attributes are stored must be noted. Rules can then be created by constructing wildcard-based filters.
  • SELinux must be in the Permissive or Disabled mode to enable object access for the existing filesets.
  • The conditional request, such as If-Match and If-None-Match when used with swift or curl client that does ETag comparison does not work for the existing data that is enabled for object access by using the mmobj file-access link-fileset command. If the --update-listing option is used, the feature can be used after the objectizer service interval.
  • The swift and curl clients might report successful container deletion after a delete operation is triggered on a container that contains linked filesets. So, the directory corresponding to the container and the symlinks of the linked filesets are not deleted and must be deleted manually.
  • The swift COPY API (when used on linked fileset) does not copy the object metadata. Use the swift POST API instead.
  • The performance of the objectization process is impacted by the size and the concurrent usage of the associated containers. Because the objectization process compares the files in the fileset to the objects in the container databases, performance degrades as the containers get larger or if the container usage is high during the objectization process.