[LU-10995] DoM2: allow MDT-only filesystems Created: 03/May/18  Updated: 16/Jan/22

Status: Open
Project: Lustre
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: Andreas Dilger Assignee: WC Triage
Resolution: Unresolved Votes: 0
Labels: DoM2

Issue Links:
Related
is related to LU-10176 Data-on-MDT phase II Open
is related to LU-11471 IO Errors during failover with very ... Closed
is related to LU-11023 OST Pool Quotas Resolved
is related to LU-11421 DoM: manual migration OST-MDT, MDT-MDT Resolved
is related to LU-11425 Support quota for DoM Resolved
Rank (Obsolete): 9223372036854775807

 Description   

We don't yet support all-MDT systems, but I'm sure it is only a matter of time until we do. I think the main limitation is that we don't allow clients to use the filesystem until the MDS has connected to at least one OST, to prevent clients just getting errors when trying to use the filesystem (before DoM).

We probably also need some testing to ensure we allow DoM file creates without OST components even if no OSTs are connected. We might also need to lift the 1GB dom_stripesize limit in that case.

Finally, we might need to handle MDT and OST on the same node better during recovery, but it might also just work since the MDT always uses the same connection UUID.



 Comments   
Comment by Mikhail Pershin [ 16/Jan/22 ]

Copied from LU-11471 to have all related notes in one ticket:

With the advent of Data-on-MDT we will at some point want to allow filesystems with only MDTs to be created. At that point, this check has to be removed.

As a starting point, we could add a tunable that allows this behavior to be selected by the admin - return an error if no OSTs are available, or cause the client to block and wait for an OST to become available. I think in the case where an OST was previously available, but they are temporarily offline due to failover, the client should block. If the file being created has a DoM component at the start, then it should not block.

Generated at Sat Feb 10 02:40:01 UTC 2024 using Jira 9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c.