Compatibility Between OBS APIs and PFS
You can call some OBS APIs to use PFS. There may be additional requirements when you call these APIs.
For details about the OBS APIs, see Object Storage Service API Reference.
APIs for Basic Bucket Operations
Table 1 APIs for basic bucket operations
API |
PFS Compatible |
Differences |
Listing buckets |
Yes |
The x-obs-bucket-type:POSIX header is required for obtaining the list of parallel file systems. |
Creating a bucket |
Yes |
The x-obs-fs-file-interface:Enabled header is required for creating a parallel file system. |
Lists objects in a bucket |
Yes |
- |
Obtaining bucket metadata |
Yes |
- |
Obtaining bucket region locations |
Yes |
- |
Deleting a bucket |
Yes |
- |
APIs for Advanced Bucket Settings
Table 2 APIs for advanced bucket settings
API |
PFS Compatible |
Differences |
Configuring a Bucket Policy |
Yes |
- |
Obtaining bucket policy information |
Yes |
- |
Deleting a bucket policy |
Yes |
- |
Configuring a bucket ACL |
Yes |
- |
Obtaining bucket ACL information |
Yes |
- |
Configuring logging for a bucket |
Yes |
- |
Obtaining a bucket logging configuration |
Yes |
- |
Configuring bucket lifecycle rules |
Yes |
- |
Obtaining bucket lifecycle configuration |
Yes |
- |
Deleting bucket lifecycle rules |
Yes |
- |
Configuring versioning for a bucket |
No |
- |
Obtaining bucket versioning status |
No |
- |
Configuring event notification for a bucket |
Yes |
- |
Obtains the event notification configuration of a bucket |
Yes |
- |
Configuring storage class for a bucket |
No |
- |
Obtaining bucket storage class information |
No |
- |
Configuring cross-region replication for a bucket |
No |
- |
Obtaining the cross-region replication configuration of a bucket |
No |
- |
Deleting the cross-region replication configuration of a bucket |
No |
- |
Configuring tags for a bucket |
Yes |
- |
Obtaining bucket tags |
Yes |
- |
Deleting bucket tags |
Yes |
- |
Configuring bucket storage quota |
Yes |
- |
Querying bucket storage quota |
Yes |
- |
Querying information about used space in a bucket |
Yes |
- |
Configuring bucket inventories |
No |
- |
Obtaining bucket inventories |
No |
- |
Listing bucket inventories |
No |
- |
Deleting bucket inventories |
No |
- |
Configuring a custom domain name for a bucket |
Yes |
- |
Obtaining the custom domain name of a bucket |
Yes |
- |
Deleting a custom domain name of a bucket |
Yes |
- |
Configuring bucket encryption |
No |
- |
Obtaining bucket encryption configuration |
No |
- |
Deleting the encryption configuration of a bucket |
No |
- |
Configuring the direct reading policy for Archive objects in a bucket |
Yes |
- |
Obtaining the direct reading policy for Archive objects in a bucket |
Yes |
- |
Deleting the direct reading policy for Archive objects in a bucket |
Yes |
- |
APIs for Static Website Hosting
Table 3 APIs for static website hosting
API |
PFS Compatible |
Differences |
Configuring static website hosting for a bucket |
No |
- |
Obtaining the static website hosting configuration of a bucket |
No |
- |
Deleting the static website hosting configuration of a bucket |
No |
- |
Configuring bucket CORS |
Yes |
- |
Obtaining the CORS configuration of a bucket |
Yes |
- |
Deleting the CORS configuration of a bucket |
Yes |
- |
OPTIONS buckets |
No |
- |
OPTIONS objects |
No |
- |
APIs for Object Operations
Table 4 APIs for object operations
API |
PFS Compatible |
Differences |
PUT objects |
Yes |
- Headers not supported: x-obs-storage-class, x-obs-website-redirect-location, success-action-redirect, and x-obs-expires
- Objects uploaded using this API cannot be directly stored in the Infrequent Access or Archive storage class and are stored in the Standard storage class by default. You can later change the storage class by using a lifecycle rule or modifying the metadata.
|
POST objects |
Yes |
Headers not supported: x-obs-storage-class, x-obs-website-redirect-location, success-action-redirect, and x-obs-expires |
Copying objects |
Yes |
Data can be replicated only between parallel file systems or buckets that are in the same cluster. |
Obtaining object content |
Yes |
- |
Obtaining object metadata |
Yes |
- |
Deleting an object |
Yes |
- |
Batch deleting objects |
Yes |
- |
Restoring Archive objects |
√ |
- |
Appending objects |
No |
- |
Configuring object ACL |
Yes |
- |
Obtaining object ACL information |
Yes |
- |
Modifying object metadata |
Yes |
In a parallel file system, the storage class of a directory cannot be changed. To change the storage class of a file in the directory, modify the metadata of the file or use a lifecycle rule to change the storage class of files in batches. |
Modifying an object |
Yes |
This is a PFS only API, and is not supported by OBS buckets. |
Truncating an object |
Yes |
This is a PFS only API, and is not supported by OBS buckets. |
Renaming an object |
Yes |
This is a PFS only API, and is not supported by OBS buckets. |
APIs for Multipart Uploads
Table 5 APIs for multipart uploads
API |
PFS Compatible |
Differences |
Listing initialized multipart tasks in a bucket |
Yes |
- |
Initiating multipart upload tasks |
Yes |
- |
Uploading parts |
Yes |
- |
Copying parts |
Yes |
Copying parts is not supported for an appended file. |
Listing uploaded parts |
Yes |
- |
Merging parts |
Yes |
- |
Canceling multipart tasks |
Yes |
- |
Permissions Configuration
The use cases and main functions of object access control also work on files in parallel file systems. For more information, see Permissions Configuration Guide.
Differences Between File and Object Permission Configurations
To exactly match a specific directory, the resource path in the policy must end with a slash (/). When checking permissions, parallel file systems consider objects as directories. Since objects do not end with a slash (/), PFS will add a slash (/) to the end of objects and then perform a policy matching.
IAM Permission Configuration Examples
Example 1: Grant a user the permissions required to download dir_1, excluding its subdirectories.
In the following configuration, the resource path ends with a slash (/). In such case, a success response can be returned when dir_1 or dir_1/ is contained in the URL of a head request.
Note that this configuration is not applied to subdirectories or files in dir_1. Therefore, a failure response will be returned if a head request is sent to dir_1/file1.
{
"Version": "1.1",
"Statement": [
{
"Effect": "Allow",
"Action": [
"obs:object:GetObject",
],
"Resource": [
"obs:*:*:object:examplebucket/dir_1/",
]
}
]
}
Example 2: Grant a user the permissions required to download dir_1 and its subdirectories.
In the following configuration, the resource path uses prefix-based matching and ends with a wildcard (*). In such case, a success response can be returned when a head request is sent to dir_1/file1.
{
"Version": "1.1",
"Statement": [
{
"Effect": "Allow",
"Action": [
"obs:object:GetObject",
],
"Resource": [
"obs:*:*:object:examplebucket/dir_1/*",
]
}
]
}
Bucket Policy Configuration Examples
Example 1: Grant a user the permissions required to download dir_1, excluding its subdirectories.
In the following configuration, the resource path ends with a slash (/). In such case, a success response can be returned when dir_1 or dir_1/ is contained in the URL of a head request.
{
"Statement":[
{
"Sid":"test",
"Effect":"Allow",
"Principal": {"ID": ["domain/b4bf1b36d9ca43d984fbcb9491b6fce9:user/71f3901173514e6988115ea2c26d1999"]},
"Action":["*"],
"Resource":[
"examplebucket/dir_1/",
]
}
]
}
Lifecycle Management
The use cases and main functions of object lifecycle management also work on files in parallel file systems. For more information, see Creating a Lifecycle Rule.
To manage the lifecycle using SDKs, see SDK Overview.
Differences Between File and Object Lifecycle Management
- A lifecycle rule can be used to manage files, but it cannot transition a directory to the Archive storage class. However, a lifecycle rule can delete an empty directory upon expiration.
- File deletion upon expiration and transition to the Archive storage class can be configured using either the API or console, while transition to Infrequent Access can only be configured using the API. PFS does not support versioning, so lifecycle actions (including deletion upon expiration and transition to the Archive or Infrequent Access storage class) that are related to versioning cannot be applied.
- If direct reading is enabled for a parallel file system, you can read files stored in the Archive storage class without restoring them first.
- A maximum of 20 lifecycle rules can be configured for a parallel file system.
- The time applied for a lifecycle rule to work on a file is when the data of the file was last updated.
- Lifecycle rules cannot transition files to the Deep Archive storage.
- A lifecycle rule configured for a parallel file system has limits on how many directories it can apply to. It will take longer time to execute the actions defined in the rule if:
- There are over 100,000 level-1 subdirectories in each directory.
- There are over 10 million subdirectories (folders) matching the specified prefix in total.
- There are over 30 million files matching the specified prefix in total.
Notes for Lifecycle Management
- If renamed files or files in a renamed directory meet the conditions specified in a lifecycle rule, the time when the file data was most recently updated, not when the files were renamed, will be applied for the lifecycle rule to take effect. In addition, the effective time of the lifecycle rule may be delayed for up to seven days.
- For a file copy on a client, the lifecycle rule determines when to expire the file copy or transition it to the Archive storage class based on the file copy creation time.
- For example, if a file, src.txt, was created on January 1, 2019, and was then copied to the des.txt file by running the cp -a src.txt des.txt command on September 1, 2019. Then the lifecycle rule calculated when to perform the specified actions on the file copy based on September 1, 2019.
- A lifecycle rule periodically scans directories in the file system and then deletes the directories that meet the expiration conditions. A scan starts from the deepest directory. The scanned empty directories that meet the expiration conditions will be deleted, and those non-empty directories will not be processed. Scan intervals (usually seven days) vary depending on cluster configurations. For this mechanism, a single-level directory that meets the expiration conditions will be deleted 0 to 7 days after it has been emptied. Accordingly, a two-level directory will be deleted 0 to 14 days after it has been emptied. Each time a directory level is added, the waiting time for deletion increases by seven days.