Need to record MDAL-type in xattrs (?)

[jti-lanl]

With the advent of MDAL, the MDAL for the MD-path used to write metadata could be different from the NS config MDAL because either (a) the thing is sharded (and hence uses the alternative MDAL in the NS config), or (b) the config changed. Also, (c) we might not have access to the configuration.

We might deal with (a) by simply detecting that the object is sharded (*), and using that to determine where in the configured NS to find the appropriate MDAL. But if (b) or (c) can happen, we probably need to store the dir/file MDAL in the xattrs. And, if we're going to do that, we can either go to the trouble of making it backward-compatible, or we can mark a new incompatible version.

(* which we already do, but requires a stat of the parent-dir.)

[brettkettering]

Jeff will confirm whether or not this is done.

[jti-lanl]

Not started. (In our conversation, I was thinking of the changes in 85ccf6a, which is different.)

[Reference to things "we already do", concerns development that was aimed at the original "sharding" spec, before we decided to just do everything in the MDAL. That development code is probably mostly obsolete and won't get into the master. Thus, we don't "already do" that, anymore.]

The core idea behind this issue is:

• "what if someone changes the configured MDAL for a namespace?"

All the existing files might be hosed. But is it worth adding more xattr fields, and configuration changes to support versioned MDALs?

We could just say: "Never change the MDAL in a namespace configuration !!"

If we go this route, then the smart way to update MDALs would be to create a new NS, with the newer MDAL, and write some sort of MD migration-tool, like pftool for metadata: read with the old MDAL (readdir, stat, getxattrs, etc), write with the new one.

• But, what if someone just changes the implementation of an MDAL function, or two, affecting many namespaces?

We could also just say: "If you change an MDAL function in an incompatible way, you must (a) increment the marfs-version, and (b) forever check versions of files handled by that function" (until you migrate to a NS with a fresh version).

That's way uglier than saving the MDAL-version in an xattr, and just selecting the right one at run-time. On the other hand, that would create a lot of rarely-used xattr crap. (No, we'd use it every time we accessed the MD.)

• What if I want to start sharding directories, because the NS is getting crowded?

You should have used the shardable MDAL from the beginning? Create a new NS and migrate your metadata.

Okay. Better way to phrase it: We're going to have bugs/design-changes in the MDAL, how do we want to fix them?

(1) MDAL-version-in-xattr buys a complete (mostly-)unchanging MDAL associated with each file. Versioning is in the config-file, where there are a bunch of complete MDALs. There's a run-time MDAL-lookup for many MDAL operations. (But only once per file-handle.)

(2) the tough-love approach (fixed MDAL per NS) suggests some versioning inside individual functions. We also have MDAL versions, they just always apply to a complete NS, with special-cases based on the MarFS-version of a file. All files in a given NS have the same problems.

In both cases: Maybe you can change the MDAL in a populated NS without having to migrate, depending on the change. Probably have to migrate to use new capabilities.