On Mon, Aug 5, 2019 at 11:43 AM Ilya Dryomov wrote:
> On Tue, Jul 30, 2019 at 10:33 AM Massimo Sgaravatto
> wrote:
> >
> > The documentation that I have seen says that the minimum requirements
> for clients to use upmap are:
> >
> > - CentOs 7.5 or kernel 4.5
> > - Luminous version
>
> Do you ha
On Tue, Jul 30, 2019 at 10:33 AM Massimo Sgaravatto
wrote:
>
> The documentation that I have seen says that the minimum requirements for
> clients to use upmap are:
>
> - CentOs 7.5 or kernel 4.5
> - Luminous version
Do you have a link for that?
This is wrong: CentOS 7.5 (i.e. RHEL 7.5 kernel)
On Tue, Jul 30, 2019 at 2:06 AM Janne Johansson wrote:
> Someone should make a webpage where you can enter that hex-string and get
> a list back.
>
Providing a minimum bitmap would allow someone to do so, and someone like
me to do it manually until then.
Robert LeBlanc
PGP Finge
Den tis 30 juli 2019 kl 10:33 skrev Massimo Sgaravatto <
massimo.sgarava...@gmail.com>:
> The documentation that I have seen says that the minimum requirements for
> clients to use upmap are:
> - CentOs 7.5 or kernel 4.5
> - Luminous version
> E.g. right now I am interested about 0x1ffddff8eea4fff
The documentation that I have seen says that the minimum requirements for
clients to use upmap are:
- CentOs 7.5 or kernel 4.5
- Luminous version
But in general ceph admins could not have access to all clients to check
these versions.
In general: is there a table somewhere reporting the minimum
Thanks !
On Mon, Jul 29, 2019 at 5:26 PM Paul Emmerich
wrote:
> yes, that's good enough for "upmap".
>
> Mapping client features to versions is somewhat unreliable by design: not
> every new release adds a new feature, some features are backported to older
> releases, kernel clients are a comple
yes, that's good enough for "upmap".
Mapping client features to versions is somewhat unreliable by design: not
every new release adds a new feature, some features are backported to older
releases, kernel clients are a completely independent implementation not
directly mapable to a Ceph release.
I have a ceph cluster where mon, osd and mgr are running ceph luminous
If I try running ceph features [*], I see that clients are grouped in 2
sets:
- the first one appears using luminous with features 0x3ffddff8eea4fffb
- the second one appears using luminous too, but with
features 0x3ffddff8eea
So I assume there are 3 ceph applications (e.g. three VMs) on the jewel
host, and 5 applications on the two luminous hosts.
To be clear - client is not VM, client is disk. If one VM have 3 disks -
'ceph features' show 3 clients.
k
___
ceph-users mai
Thanks for your answer
Actually I have the very same configuration on the three "client hosts": on
each of them I simply mapped a single rbd volume ...
Cheers, Massimo
2017-12-15 11:10 GMT+01:00 Burkhard Linke <
burkhard.li...@computational.bio.uni-giessen.de>:
> Hi,
>
>
> On 12/15/2017 10:56 A
Hi,
On 12/15/2017 10:56 AM, Massimo Sgaravatto wrote:
Hi
I tried the jewel --> luminous update on a small testbed composed by:
- 3 mon + mgr nodes
- 3 osd nodes (4 OSDs per each of this node)
- 3 clients (each client maps a single volume)
*snipsnap*
[*]
"client": {
"group": {
Hi
I tried the jewel --> luminous update on a small testbed composed by:
- 3 mon + mgr nodes
- 3 osd nodes (4 OSDs per each of this node)
- 3 clients (each client maps a single volume)
In short:
- I updated the 3 mons
- I deployed mgr on the 3 mon hosts
- I updated the 3 osd nodes
- I updated
12 matches
Mail list logo
