> On Oct 22, 2018, at 23:06, ? ? wrote:
>
>
> Hello:
> Do you ever encountered a similar deadlock cephfs stack?
>
> [Sat Oct 20 15:11:40 2018] INFO: task nfsd:27191 blocked for more than 120
> seconds.
> [Sat Oct 20 15:11:40 2018] Tainted: G OE
> 4.14.0-49
Hi folks,
I tried to purge a ceph cluster using
infrastructure-playbooks/purge-cluster.yml from stable 3.1 and stable 3.2
branches, but kept getting the following error immediately:
ERROR! no action detected in task. This often indicates a misspelled module
name, or incorrect module path.
The er
I don't have enough disk space on the nvme. The DB would overflow before I
reached 25% utilization in the cluster. The disks are 10TB spinners and
would need a minimum of 100 GB of DB space minimum based on early testing.
The official docs recommend 400GB size DB for this size disk. I don't have
en
Why didn't you just install the DB + WAL on the NVMe? Is this "data disk"
still an ssd?
On Mon, Oct 22, 2018 at 3:34 PM David Turner wrote:
> And by the data disk I mean that I didn't specify a location for the DB
> partition.
>
> On Mon, Oct 22, 2018 at 4:06 PM David Turner
> wrote:
>
>> Tr
Someone deleted our rgw data pool to clean up. They recreated it
afterward. This is fine in one respect, we don't need the data. But
listing with radosgw-admin still shows all the buckets. How can we clean
things up and get rgw to understand what actually exists, and what doesn't?
No, it's exactly what I told you it was. "bluestore_bdev_partition_path"
is the data path. In all of my scenarios my DB and Data are on the same
partition, hence mine are the same. Your DB and WAL are on a different
partition from your Data... so your DB partition is different... Whatever
your m
That's very helpful, thanks. In your first case above your
bluefs_db_partition_path and bluestore_bdev_partition path are the same.
Though I have a different data and db drive, mine are different. Might
this explain something? My root concern is that there is more utilization
on the cluster tha
My DB doesn't have a specific partition anywhere, but there's still a
symlink for it to the data partition. On my home cluster with all DB, WAL,
and Data on the same disk without any partitions specified there is a block
symlink but no block.wal symlink.
For the cluster with a specific WAL partit
Let me add, I have no block.wal file (which the docs suggest should be
there).
http://docs.ceph.com/docs/master/rados/configuration/bluestore-config-ref/
On Mon, Oct 22, 2018 at 3:13 PM Robert Stanford
wrote:
>
> We're out of sync, I think. You have your DB on your data disk so your
> block.d
We're out of sync, I think. You have your DB on your data disk so your
block.db symlink points to that disk, right? There is however no wal
symlink? So how would you verify your WAL actually lived on your NVMe?
On Mon, Oct 22, 2018 at 3:07 PM David Turner wrote:
> And by the data disk I mean
Track down where it says they point to? Does it match what you expect? It
does for me. I have my DB on my data disk and my WAL on a separate NVMe.
On Mon, Oct 22, 2018 at 3:21 PM Robert Stanford
wrote:
>
> David - is it ensured that wal and db both live where the symlink
> block.db points?
And by the data disk I mean that I didn't specify a location for the DB
partition.
On Mon, Oct 22, 2018 at 4:06 PM David Turner wrote:
> Track down where it says they point to? Does it match what you expect?
> It does for me. I have my DB on my data disk and my WAL on a separate NVMe.
>
> On M
David - is it ensured that wal and db both live where the symlink block.db
points? I assumed that was a symlink for the db, but necessarily for the
wal, because it can live in a place different than the db.
On Mon, Oct 22, 2018 at 2:18 PM David Turner wrote:
> You can always just go to /var/li
You can always just go to /var/lib/ceph/osd/ceph-{osd-num}/ and look at
where the symlinks for block and block.wal point to.
On Mon, Oct 22, 2018 at 12:29 PM Robert Stanford
wrote:
>
> That's what they say, however I did exactly this and my cluster
> utilization is higher than the total pool ut
I haven't had crush-compat do anything helpful for balancing my clusters.
upmap has been amazing and balanced my clusters far better than anything
else I've ever seen. I would go so far as to say that upmap can achieve a
perfect balance.
It seems to evenly distribute the PGs for each pool onto al
That's what they say, however I did exactly this and my cluster
utilization is higher than the total pool utilization by about the number
of OSDs * wal size. I want to verify that the wal is on the SSDs too but
I've asked here and no one seems to know a way to verify this. Do you?
Thank you, R
Hello:
Do you ever encountered a similar deadlock cephfs stack?
[Sat Oct 20 15:11:40 2018] INFO: task nfsd:27191 blocked for more than 120
seconds.
[Sat Oct 20 15:11:40 2018] Tainted: G OE
4.14.0-49.el7.centos.x86_64 #1
[Sat Oct 20 15:11:40 2018] "echo 0 > /proc
Hi all,
I follow below guide to deploy ceph mimic packages on ubuntu 16.04 host.
http://docs.ceph.com/docs/master/start/quick-ceph-deploy/
I always hit below problem:
[DEBUG ] Setting up ceph-mon (13.2.2-1xenial) ...
[DEBUG ] start: Unable to connect to Upstart: Failed to connect to
On Mon, Oct 22, 2018 at 7:47 PM Dylan McCulloch wrote:
>
> > On Mon, Oct 22, 2018 at 2:37 PM Dylan McCulloch
> > wrote:
> > >
> > > >
> > > > On Mon, Oct 22, 2018 at 9:46 AM Dylan McCulloch
> > > > wrote:
> > > > >
> > > > > On Mon, Oct 8, 2018 at 2:57 PM Dylan McCulloch > > > > unimelb.edu.a
> On Mon, Oct 22, 2018 at 2:37 PM Dylan McCulloch wrote:
> >
> > >
> > > On Mon, Oct 22, 2018 at 9:46 AM Dylan McCulloch
> > > wrote:
> > > >
> > > > On Mon, Oct 8, 2018 at 2:57 PM Dylan McCulloch >
> > > > wrote:
> > > > >>
> > > > >> Hi all,
> > > > >>
> > > > >>
> > > > >> We have identified
It may be related to http://tracker.ceph.com/issues/34307 - I have a
cluster whose OMAP size is larger than the stored data...
On Mon, Oct 22, 2018 at 11:09 AM Wido den Hollander wrote:
>
>
>
> On 8/31/18 5:31 PM, Dan van der Ster wrote:
> > So it sounds like you tried what I was going to do, and
If you specify a db on ssd and data on hdd and not explicitly specify a
device for wal, wal will be placed on same ssd partition with db.
Placing only wal on ssd or creating separate devices for wal and db are
less common setups.
/Maged
On 22/10/18 09:03, Fyodor Ustinov wrote:
Hi!
For sha
On 8/31/18 5:31 PM, Dan van der Ster wrote:
> So it sounds like you tried what I was going to do, and it broke
> things. Good to know... thanks.
>
> In our case, what triggered the extra index objects was a user running
> PUT /bucketname/ around 20 million times -- this apparently recreates
> t
On Mon, Oct 22, 2018 at 2:37 PM Dylan McCulloch wrote:
>
> >
> > On Mon, Oct 22, 2018 at 9:46 AM Dylan McCulloch wrote:
> > >
> > > On Mon, Oct 8, 2018 at 2:57 PM Dylan McCulloch >
> > > wrote:
> > > >>
> > > >> Hi all,
> > > >>
> > > >>
> > > >> We have identified some unexpected blocking behav
Hi!
For sharing SSD between WAL and DB what should be placed on SSD? WAL or DB?
- Original Message -
From: "Maged Mokhtar"
To: "ceph-users"
Sent: Saturday, 20 October, 2018 20:05:44
Subject: Re: [ceph-users] Drive for Wal and Db
On 20/10/18 18:57, Robert Stanford wrote:
Our OSDs a
25 matches
Mail list logo
