Den sön 25 nov. 2018 kl 22:10 skrev Stefan Kooman :
>
> Hi List,
>
> Another interesting and unexpected thing we observed during cluster
> expansion is the following. After we added extra disks to the cluster,
> while "norebalance" flag was set, we put the new OSDs "IN". As soon as
> we did that a
Quoting Janne Johansson (icepic...@gmail.com):
> Yes, when you add a drive (or 10), some PGs decide they should have one or
> more
> replicas on the new drives, a new empty PG is created there, and
> _then_ that replica
> will make that PG get into the "degraded" mode, meaning if it had 3
> fine a
Den mån 26 nov. 2018 kl 09:39 skrev Stefan Kooman :
> > It is a slight mistake in reporting it in the same way as an error,
> > even if it looks to the
> > cluster just as if it was in error and needs fixing. This gives the
> > new ceph admins a
> > sense of urgency or danger whereas it should be
Hi folks,
i upgraded our ceph cluster from jewel to luminous and want to migrate
from filestore to bluestore. Currently we use one SSD as journal for
thre 8TB Sata Drives with a journal partition size of 40GB. If my
understanding of the bluestore documentation is correct, i can use a wal
part
Den mån 26 nov. 2018 kl 10:10 skrev Felix Stolte :
>
> Hi folks,
>
> i upgraded our ceph cluster from jewel to luminous and want to migrate
> from filestore to bluestore. Currently we use one SSD as journal for
> thre 8TB Sata Drives with a journal partition size of 40GB. If my
> understanding of t
Hello,
Can anyone say how important is to have fast storage on monitors for a
all ssd deployment? We are planning on throwing SSDs into the monitors
as well, but are at a loss about if to go for more durability or speed.
Higher durability drives tend to be a lot slower for the 240GB size we'd
Hi,
El 25/11/18 a las 18:23, Виталий Филиппов escribió:
Ok... That's better than previous thread with file download where the
topic starter suffered from normal only-metadata-journaled fs...
Thanks for the link, it would be interesting to repeat similar tests.
Although I suspect it shouldn't b
Mandi! Janne Johansson
In chel di` si favelave...
> The default crush rules with replication=3 would only place PGs on
> separate hosts,
> so in that case it would go into degraded mode if a node goes away,
> and not place
> replicas on different disks on the remaining hosts.
'hosts' mean 'host
Haven't seen that exact issue.
One thing to note though is that if osd_max_backfills is set to 1,
then it can happen that PGs get into backfill state, taking that
single reservation on a given OSD, and therefore the recovery_wait PGs
can't get a slot.
I suppose that backfill prioritization is supp
Den mån 26 nov. 2018 kl 12:11 skrev Marco Gaiarin :
> Mandi! Janne Johansson
> In chel di` si favelave...
>
> > The default crush rules with replication=3 would only place PGs on
> > separate hosts,
> > so in that case it would go into degraded mode if a node goes away,
> > and not place
> > repl
Quoting Dan van der Ster (d...@vanderster.com):
> Haven't seen that exact issue.
>
> One thing to note though is that if osd_max_backfills is set to 1,
> then it can happen that PGs get into backfill state, taking that
> single reservation on a given OSD, and therefore the recovery_wait PGs
> can'
Mandi! Janne Johansson
In chel di` si favelave...
> It is a slight mistake in reporting it in the same way as an error, even if
> it looks to the
> cluster just as if it was in error and needs fixing.
I think i'm hit a similar situation, and also i'm feeling that
something have to be 'fixed'.
On Mon, Nov 26, 2018 at 3:30 AM Janne Johansson wrote:
> Den sön 25 nov. 2018 kl 22:10 skrev Stefan Kooman :
> >
> > Hi List,
> >
> > Another interesting and unexpected thing we observed during cluster
> > expansion is the following. After we added extra disks to the cluster,
> > while "norebala
On Sun, Nov 25, 2018 at 2:41 PM Stefan Kooman wrote:
> Hi list,
>
> During cluster expansion (adding extra disks to existing hosts) some
> OSDs failed (FAILED assert(0 == "unexpected error", _txc_add_transaction
> error (39) Directory not empty not handled on operation 21 (op 1,
> counting from 0
As the monitors limit their transaction rates, I would tend for the
higher-durability drives. I don't think any monitor throughput issues have
been reported on clusters with SSDs for storage.
-Greg
On Mon, Nov 26, 2018 at 5:47 AM Valmar Kuristik wrote:
> Hello,
>
> Can anyone say how important i
On 11/26/18 2:21 PM, Gregory Farnum wrote:
> As the monitors limit their transaction rates, I would tend for the
> higher-durability drives. I don't think any monitor throughput issues
> have been reported on clusters with SSDs for storage.
I can confirm that. Just make sure you have proper Dat
On Fri, Nov 23, 2018 at 11:01 AM ST Wong (ITSC) wrote:
> Hi all,
>
>
> We've 8 osd hosts, 4 in room 1 and 4 in room2.
>
> A pool with size = 3 using following crush map is created, to cater for
> room failure.
>
>
> rule multiroom {
> id 0
> type replicated
> min_size 2
>
On Tue, Nov 20, 2018 at 9:50 PM Vlad Kopylov wrote:
> I see the point, but not for the read case:
> no overhead for just choosing or let Mount option choose read replica.
>
> This is simple feature that can be implemented, that will save many
> people bandwidth in really distributed cases.
>
T
Hello
I am doing some Ceph testing on a near-full cluster, and I noticed that,
after I brought down a node, some OSDs' utilization reached
osd_failsafe_full_ratio (97%). Why didn't it stop at mon_osd_full_ratio
(90%) if mon_osd_backfillfull_ratio is 90%?
Thanks,
Vlad
__
> Why didn't it stop at mon_osd_full_ratio (90%)
Should be 95%
Vlad
On 11/26/18 9:28 AM, Vladimir Brik wrote:
Hello
I am doing some Ceph testing on a near-full cluster, and I noticed that,
after I brought down a node, some OSDs' utilization reached
osd_failsafe_full_ratio (97%). Why didn't
I see. Thank you Greg.
Ultimately leading to some kind of multi-primary OSD/MON setup, which
will most likely add lookup overheads. Though might be a reasonable
trade off for network distributed setups.
Good feature for major version.
With Glusterfs I solved it, funny as it sounds, by writing tin
On Mon, Nov 26, 2018 at 10:28 AM Vladimir Brik
wrote:
>
> Hello
>
> I am doing some Ceph testing on a near-full cluster, and I noticed that,
> after I brought down a node, some OSDs' utilization reached
> osd_failsafe_full_ratio (97%). Why didn't it stop at mon_osd_full_ratio
> (90%) if mon_osd_ba
On Thu, Nov 22, 2018 at 11:47 AM Matthew Vernon wrote:
>
> On 22/11/2018 13:40, Paul Emmerich wrote:
> > We've encountered the same problem on Debian Buster
>
> It looks to me like this could be fixed simply by building the Bionic
> packages in a Bionic chroot (ditto Buster); maybe that could be d
Hi Alexander,
On 11/13/18 12:37 PM, Kasper, Alexander wrote:
> As i am not sure howto correctly use tracker.ceph.com, i´ll post my
> report here:
>
> Using the dashboard to delete a rbd image via gui throws an error when
> the image name ends with an whitespace (user input error leaded to this
>
Hello,
I have a Ceph cluster deployed together with OpenStack using TripleO.
While the Ceph cluster shows a healthy status, its performance is
painfully slow. After eliminating a possibility of network issues, I
have zeroed in on the Ceph cluster itself, but have no experience in
further debugging
Hi all,
We have planning to use SSD data drive, so for journal drive, is there any
recommendation to use same drive or separate drive?
Thanks,
Amit
___
ceph-users mailing list
ceph-users@lists.ceph.com
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.
Hello,
what type of SSD data drives do you plan to use?
In general, I would not recommend to use external journal on ssd OSDs, but
it is possible to squeeze out a bit more performance depending on your data
disks.
--
Martin Verges
Managing director
Mobile: +49 174 9335695
E-Mail: martin.ver...@
On Tue, 27 Nov 2018, 10:55 Martin Verges, wrote:
> Hello,
>
> what type of SSD data drives do you plan to use?
>
We have plan to using external ssd data drive.
> In general, I would not recommend to use external journal on ssd OSDs, but
> it is possible to squeeze out a bit more performance depe
Hi all,
I need to move instance from one Openstack with Ceph to another
different Openstack with Ceph installation. The instance use volume to
boot with another volume attach for data. The instance has 200GB volume
boot and attach with 1TB volume for data.
From what I know, I need to downloa
Quoting Cody (codeology@gmail.com):
> The Ceph OSD part of the cluster uses 3 identical servers with the
> following specifications:
>
> CPU: 2 x E5-2603 @1.8GHz
> RAM: 16GB
> Network: 1G port shared for Ceph public and cluster traffics
This will hamper throughput a lot.
> Journaling device
Hi,guysI have a 42 nodes cluster,and I create the pool using expected_num_objects to pre-split filestore dirs.today I rebuild a osd because a disk error,it cause much slow request,filestore logs like below2018-11-26 16:49:41.003336 7f2dad075700 10 filestore(/home/ceph/var/lib/osd
31 matches
Mail list logo
