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
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
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
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
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:
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
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
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
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
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
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
> 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
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
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.
>
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 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
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
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
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
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'.
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
>
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
> >
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
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
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
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
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
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
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
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
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
31 matches
Mail list logo
