[LU-17691] add interface to deregister file system/targets on MGS

• Type: Improvement
• Resolution: Fixed
• Priority: Major
• Affects Version/s: Lustre 2.15.4
• Labels: llnl
• Severity: 3
• Assignee: Peter Jones
• Reporter: Olaf Faaland

Description

When one starts a target with the writeconf option, it registers with the MGS, resulting in the creation of config llog files.

In the case of an MGS which is separate from MDT0, and shared among multiple file systems, those config logs will accumulate.

As far as I can tell, there is no mechanism for removing the relevant config llog files when a file system, and all its targets, are destroyed.

First question, am I correct that there is no such mechanism now?

 

(edited later: I was mistaken, Andreas pointed out that there is a command for deleting the config llog files, "lctl erase_lcfg FSNAME" which is run on the MGS to delete all of the config logs for FSNAME. )

Issue Links

• is related to: LU-16722 MGS config log restructuring

Comments

[Olaf Faaland]

The command Andreas pointed out is what I was looking for.  Sanity checks would be nice, if they are possible, but this will do.

[Olaf Faaland]

AFAIK, there are no sanity checks for this command at all today

OK, good to know.

Potentially there could be such checks, since the MGS could determine whether there are clients referencing a particular configuration. On the flip side, this might also be true if there are old clients referencing a config from a filesystem where the servers were all removed and the admin is trying to remove the config so the clients can no longer try and mount the filesystem...

Isn't it normally the case that any client which has a file system mounted holds an ldlm read lock on the FSNAME-client llog? And in that case, could the mgs ask ldlm somehow whether there are any connected clients holding read locks, to provide such a sanity check?

[Andreas Dilger]

AFAIK, there are no sanity checks for this command at all today. Potentially there could be such checks, since the MGS could determine whether there are clients referencing a particular configuration. On the flip side, this might also be true if there are old clients referencing a config from a filesystem where the servers were all removed and the admin is trying to remove the config so the clients can no longer try and mount the filesystem...

[Olaf Faaland]

Thanks Andreas, that's great.

Does "lctl erase_lcfg FSNAME" prevent one from deleting the config llog files for a filesystem which is mounted by one or more clients (while they're connected to the MGS and have a lock on the relevant llog)? Same question re: mounted MDTs or OSTs?

I looked briefly at the code and see it interacts with the barrier mechanism created for snapshots, but it wasn't easy for me to see whether it interacted with ldlm at all.

[Andreas Dilger]

I forgot there is actually a command to delete all of the configuration llog files for a filesystem at once. Running "lctl erase_lcfg_FSNAME" on the MGS will delete all of the config logs for FSNAME.

[Andreas Dilger]

You can use "lctl [--device MGS] llog_catlist" to print the list of config logs, then "lctl [--device MGS] llog_remove FSNAME-MDTxxxx" and "... FSNAME-OSTxxxx" to delete the individual config logs. Most filesystems we deploy have a separate MGT device floating among the MDS nodes for each filesystem, so this config log accumulation doesn't become an issue. I could imagine a dedicated MGS failover pair useful at LLNL with several filesystems, so that Imperative Recovery is still available when any of the MDS nodes restarts.

One day soon we might start to work on LU-16722 to implement redundant MGT devices running on multiple MDS nodes concurrently, so that there isn't a need for MGS HA/failover at all.