6.3.3 HP StoreAll OS Release Notes (AW549-96082, January 2014)

The file system does not need to be unmounted when Express Query settings are
enabled on a file system
The 6.3 HP StoreAll Storage CLI Reference Guide says that the file system must be unmounted while
running the ibrix_fs -T -E -f FSNAME command to enable Express Query settings on a file
system. The file system does not need to be unmounted to run the command.
Permissions cannot be assigned to objects individually for object mode shares
The “Creating StoreAll REST API shares” section in the 6.3 HP StoreAll Storage File System User Guide
says that objects (files) are always created with permissions 0700. Permissions cannot be assigned
to objects individually. Access to a container’s objects by other users is controlled at the container
level.
Attribute names and value requirements
The “Upload custom metadata” section in the 6.3 HP StoreAll Storage File System User Guide says
that the attribute name and value must each have less than 80 characters in length when in reality the
attribute name and value must each have 80 characters or less in length.
Object mode API
In the "Best practices for HTTP REST API shares" section in the HP StoreAll Storage File System User
Guide, the text about putting object mode shares on retention-enabled file systems incorrectly mentions
the auto-commit feature. The correct text is:
Avoid putting object mode shares on retention-enabled file systems. The object mode API does not
include retention management features. Managing WORM or retention states must be performed
outside the API as described in the “Managing data retention” section.
In the "Object mode shares and data retention" section of the User Guide, references to the auto-commit
feature are incorrect. The correct text is:
If you choose to put an object mode API share on a retention-enabled file system, there are a few
differences in how WORM and retention operate for object mode shares. Auto-commit is disabled.
Files can be manually set to WORM by clearing all write permission bits, but files cannot be retained.
A WORM object cannot be modified nor replaced via the API, but it can be deleted since retention
is disabled.
Understanding how autocommit and data retention works
Depending on the defined autocommit and retention periods, it is possible that some files may not be
retained or a file may have a reduced retention period. Although a time period is set for autocommit
and retention, there are other factors considered before autocommit or retention is applied, such as
when the file's contents or metadata were last changed (ctime) and when only the file's contents were
last changed (mtime). ctime is used to determine when autocommit should be applied. Once a decision
is made about autocommit, mtime is used to calculate the retention period.
Autocommit is calculated as follows:
ctime (T) + autocommit (x min) >= current system time = autocommit is
applied
For example, the autocommit period is 10 minutes. If ctime (T) + autocommit (10 min), which is T+10,
and the current time is equal to or greater than T+10, then autocommit is applied.
Data retention is calculated as follows:
mtime + autocommit period + retention period = retention expiration time
If the retention expiration time is greater than the current system time, then the file is retained for the
amount of time that equals retention expiration time minus the current system time. If not, the file is not
retained.
Documentation changes and additions 35