Metadata save states
Every Master Server reports how its own last metadata save was made. Each value means something different about the server that reported it.
The value appears in the metadata servers table of the GUI, in the status column of the Last metadata save group. It also appears in the last save status column of mfscli -SIM. The cluster shows its own message next to the value. The alerts reference lists the messages.
| Status | In mfscli | What the Master Server did |
|---|---|---|
| Background save | Saved in background | A separate process wrote the metadata file to disk. |
| CRC background save PRO (PRO Edition only) | CRC saved in background | A separate process went through the save and kept only the checksum. |
| Got from other PRO (PRO Edition only) | Downloaded from other master | The copy on disk came from another Master Server. |
| Foreground save | Saved in foreground | The mfsmaster process wrote the file itself. |
None of the four reports a failure. A Master Server whose save cycle cannot write the file does not keep running. It logs the reason and terminates. Every other save that ends without a file leaves the previous value unchanged. This includes a failed save that an operator asked for. It also includes a save that was cut short because the Master Server was stopped or because it changed role PRO (PRO Edition only). The status then still describes the previous save. A code outside the four is reported as an unknown status and graded as a warning. This status means that the tool that reads the Master Server does not recognize the code.
A background save keeps the Master Server answering
To save, a Master Server starts a second process. This process appears in the process list as mfsmaster (metadata saver). It writes the file and exits, while the original process continues to serve clients. The server reports Background save after such a process has finished cleanly. Background save is the expected state on every instance. A separate mechanism decides what starts a save, how often a save runs, and how many copies stay on disk. The metadata save cycle describes this mechanism.
A foreground save blocks the Master Server
A foreground save does the same work in the main process. The mfsmaster process writes the file itself and answers nothing until the save is finished. The instance is therefore blocked for as long as the save takes. A Master Server reports a foreground save after any save made without the separate process. A clean stop makes such a save, and so does the offline restore of a metadata file. Both end the process together with the save, so no tool reads the status back from them. Since 5.2.0, a running Master Server also saves in the foreground when the system refuses to start the separate process. The log then has fork error (store data in foreground - it will block master for a while), which on Linux adds - check /proc/sys/vm/overcommit_memory and if necessary set to 1 before the closing parenthesis. The Master Server keeps running, and the status reads Saved in foreground. A checksum-only save is not repeated in the foreground. It ends with can't store metadata crc and leaves the status unchanged. Foreground save is the only one of the four that the cluster grades as a warning.
A CRC background save writes no metadata file
A CRC background save PRO (PRO Edition only) runs in a separate process like an ordinary save and goes through the whole metadata, but the result is discarded. Only the checksum is kept. The metadata file on disk stays as the previous save left it. This run rewrites the checksum file beside the metadata file. The pair then no longer describes one moment. The reported save time and duration still change to the values of that run. On a server whose last status is a CRC background save, the copy on disk is therefore older than the reported save time. The mode is not part of any schedule. An operator requests it with mfssupervisor -s C. The order applies to the whole group. Every synchronized Follower stores its checksum in the same round. The Leader then compares the tables. The page on the metadata checksum describes what happens to the checksum after that.
Got from other means that the file was fetched
A Master Server reports Got from other PRO (PRO Edition only) when the file on its disk was fetched rather than written. A Leader can get the metadata file from a synchronized Follower instead of writing a file itself. The Leader downloads that file and checks that it is complete and not truncated. The Leader then replaces its own copy with that file. The Leader serialized nothing, so it reports neither a saved metadata version nor a checksum for that copy. Both columns show -. The value stays until that Master Server saves a file of its own.