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-version
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
_______________________________________________
ceph-users mailing list -- ceph-users@xxxxxxx
To unsubscribe send an email to ceph-users-leave@xxxxxxx