Details
-
Improvement
-
Resolution: Unresolved
-
Medium
-
None
-
Lustre 2.14.0, Lustre 2.16.0, Lustre 2.17.0
-
3
-
9223372036854775807
Description
It would be useful to have a mechanism to disables renames on files and directories in an HSM-archived directory tree, to prevent the filesystem directory hierarchy and its filenames becoming inconsistent with the object names in an archive bucket.
While this might not be useful for some sites, in other cases it would be important to ensure that the contents of the directory do not diverge from the object names in the (read-only?) archive, to avoid creating new objects in the bucket from archive of the "new" files that have different pathnames.
One option if there is an HSM state available on each directory in an HSM archived tree (LU-19251), would be an option like "mdt.*.enable_archive_dir_rename=0" that checks the HSM state and prevents the rename if this option is disabled. However, this has the drawback that it is a global and server-side restriction on the whole filesystem.
Another option would be to set an "immutable" attribute on the HSM restored files and directories as they are being restored from the archive. For regular files, the immutable flag can (currently) only be set and removed by root, though LU-17957 describes an "industry standard" mechanism for users to set the immutable flag on a file for document retention purposes. Alternately, an "immutable inherit" attribute (LU-18679) that could be set on a directory and then inherited by new files as they are created in the directory would also be useful.
For the directory itself, we don't want to explicitly set them immutable, or no new files can be created therein. The "append only" flag set on a directory means "new filenames can be added to the directory, but old filenames in the directory cannot be removed", which is likely more suitable for this kind of workload.
It is likely that the immutable state on HSM archived stubs needs to be relaxed, so that these files can be restored from the archive (and possibly released, if archived), but not written, truncated, or deleted. We may need to have an HSM-specific state (e.g. HS_IMMUTABLE) that allows non-modifying HSM operations to be performed, rather than using the Lustre/ldiskfs FS_IMMUTABLE_FL, which is probably too strict.
