Hello,
On Tue, 20 Sep 2016 14:40:25 +0200 Stefan Priebe - Profihost AG wrote:
> Hi Christian,
>
> Am 20.09.2016 um 13:54 schrieb Christian Balzer:
> > This and the non-permanence of reweight is why I use CRUSH reweight (a
> > more distinct naming would be VERY helpful, too) and do it manually,
Hi Christian,
Am 20.09.2016 um 13:54 schrieb Christian Balzer:
> This and the non-permanence of reweight is why I use CRUSH reweight (a
> more distinct naming would be VERY helpful, too) and do it manually, which
> tends to beat all the automated approaches so far.
so you do it really by hand and
Am 20.09.2016 um 13:49 schrieb Dan van der Ster:
> Hi Stefan,
>
> What's the current reweight value for osd.110? It cannot be increased above 1.
ah OK it's 1 already. But that doesn't make sense cause this means all
other osds (f.e. 109 osds) have to be touches to get lower values before
110 get'
Hello,
This and the non-permanence of reweight is why I use CRUSH reweight (a
more distinct naming would be VERY helpful, too) and do it manually, which
tends to beat all the automated approaches so far.
Christian
On Tue, 20 Sep 2016 13:49:50 +0200 Dan van der Ster wrote:
> Hi Stefan,
>
> Wh
Hi Stefan,
What's the current reweight value for osd.110? It cannot be increased above 1.
Cheers, Dan
On Tue, Sep 20, 2016 at 12:13 PM, Stefan Priebe - Profihost AG
wrote:
> Hi,
>
> while using ceph hammer i saw in the doc of ceph reweight-by-utilization
> that there is a --no-increasing flag
Hi,
while using ceph hammer i saw in the doc of ceph reweight-by-utilization
that there is a --no-increasing flag. I do not use it but never saw an
increased weight value even some of my osds are really empty.
Example:
821G 549G 273G 67% /var/lib/ceph/osd/ceph-110
vs.
821G 767G 54G 94% /
