On 12/17/20 5:54 PM, Patrick Donnelly wrote:
file system flags are not the same as the "feature" flags. See this doc for the feature flags:
https://docs.ceph.com/en/latest/cephfs/administration/#minimum-client-versio...
Thanks for making that clear.
Note that the new "fs feature" and "fs required_client_features" commands will be new in Pacific. They provide better control on the exact features you want to require. The old style of specifying the minimum release was inflexible and made it difficult to require specific features the kernel client supports. (For example, the kernel client is only now just about to support "nautilus" because of messenger v2 support.)
Ah, nice. Both the fs feature part as v2 support for kernel.
We would like to have the test cluster get the "1c" flags and see if we can reproduce the issue. How can we achieve that?
You can't set 0x1c directly. These correspond to reserved feature bits for unspecified older Ceph releases. Suggest you just set the min_compat_client to jewel.
Up to now we have never set a "min_compat_client". But I guess we can enforce jewel nowadays (thats the lowest ceph features gives for clients).
In any case, I think what you're asking is about the file system flags and not the required_client_features.
That's correct. So I checked the file system flags on different clusters (some installed luminous, some mimic, some nautilus) and for the clusters that started as luminous the file sytems flags are either "1c" or "1e". The ones with "1e" have been installed with newer luminous releases. So does the filesystem flags bit ever change during the lifetime of a cluster? What exactly is the purpose of the filesystem flags bit? Thanks, Gr. Stefan