On Thu, Dec 17, 2020 at 3:23 AM Stefan Kooman <stefan(a)bit.nl> wrote:
Hi List,
In order te reproduce an issue we see on a production cluster (cephFS
client: ceph-fuse outperform kernel client by a factor of 5) we would
like to have a test cluster to have the same cephfs "flags" as
production. However, it's not completely clear how certain features
influence the cephfs flags. What I could find in the source code,
cephfs_features.h, is that it *seems* to correspond to the Ceph release.
For example CEPHFS_FEATURE_NAUTILUS gets a "12" as feature bit. An
upgraded (Luminous -> Mimic -> Nautilus) cephfs gives us the following
cephfs flags: "1c".
A (newly installed) Nautilus cluster gives "10" when new snapshots are
not allowed (ceph fs set cephfs allow_new_snaps false) and "12" when new
snapshots are allowed (ceph fs set cephfs allow_new_snaps true).
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-versiā¦
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.)
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.
In any case, I think what you're asking is about the file system flags
and not the required_client_features.
--
Patrick Donnelly, Ph.D.
He / Him / His
Principal Software Engineer
Red Hat Sunnyvale, CA
GPG: 19F28A586F808C2402351B93C3301A3E258DD79D