[LU-17334] Client should handle dir/file/object created on newly added MDT/OST

Cloners — Tue, 30 Jan 2024 13:17:40 +0000

When a new MDT or OST is added to a filesystem without no_create, then a new subdirectory or file could be created on the new MDT, or a new object created on an OST relatively quickly after it is added to the filesystem, in particular because the new MDT/OST would be preferred by QOS space balancing due to lots of free space. However, it might take a few seconds for the addition of the new MDT/OST to be propagated across all of the clients, so there is a risk that the MDS creates file object on OSTs that a client is not yet aware of. There is a much smaller risk that an MDT is used for a subdirectory or file that a client is (depending on workload, if multiple clients are working in the same directory tree in parallel).

This ticket is tracking the case where a new MDT or OST is used for a subdirectory that is not in the config, then the client should either wait and retry for some short time, possibly actively pulling the config from the MGS to see if the target was newly added, instead of immediately returning an error to the application. LU-17300 is tracking the issue of not creating new subdirs/files/objects on newly-added targets in the first place.

It is still possible that the file layout is itself corrupted for whatever reason, and referencing an OST or MDT index that will never exist in the filesystem, so the client should not retry this operation indefinitely. But an (up to) ~30 second application delay while the configuration is distributed across the cluster is far preferable to the application getting an error.

Whamcloud Community JIRA

[LU-17334] Client should handle dir/file/object created on newly added MDT/OST