,
is this expected?
Thanks,
David
___
ceph-users mailing list
ceph-users@lists.ceph.com
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
HDD and SDD hosts (I didn't have any mixed devices in
hosts), set the Metadata pool to use the new rule, waited for recovery and
then set the Metadata pool to use an SSD-only rule. Not sure if that
intermediary stage was strictly necessary, I was concerned about inactive
PGs.
Thanks,
David
On Mon
eleted.'
>>
>> can anyone check MTA logs to see what the bounce is?
>
> Me too. Happens regularly and only on ceph-users, not on sepia or
> ceph-maintainers, etc. David, Dan, could you or someone you know look
> into this?
>
As far as I know, we don't have shell acces
Hi All
I'm trying to set the existing pools in a Luminous cluster to use the hdd
device-class but without moving data around. If I just create a new rule
using the hdd class and set my pools to use that new rule it will cause a
huge amount of data movement even though the pgs are all already on
I'm in a similar situation, currently running filestore with spinners and
journals on NVME partitions which are about 1% of the size of the OSD. If I
migrate to bluestore, I'll still only have that 1% available. Per the docs,
if my block.db device fills up, the metadata is going to spill back onto
Yep, that cleared it. Sorry for the noise!
On Sun, Dec 16, 2018 at 12:16 AM David C wrote:
> Hi Paul
>
> Thanks for the response. Not yet, just being a bit cautious ;) I'll go
> ahead and do that.
>
> Thanks
> David
>
>
> On Sat, 15 Dec 2018, 23:39 Paul Emmeri
Hi Paul
Thanks for the response. Not yet, just being a bit cautious ;) I'll go
ahead and do that.
Thanks
David
On Sat, 15 Dec 2018, 23:39 Paul Emmerich Did you unset norecover?
>
>
> Paul
>
> --
> Paul Emmerich
>
> Looking for help with your Ceph cluster? Contac
How would you recommend I proceed at this point?
Thanks
David
___
ceph-users mailing list
ceph-users@lists.ceph.com
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
Hi all,
I have a cluster used exclusively for cephfs (A EC "media" pool, and a standard
metadata pool for the cephfs).
"ceph -s" shows me:
---
data:
pools: 2 pools, 260 pgs
objects: 37.18 M objects, 141 TiB
usage: 177 TiB used, 114 TiB / 291 TiB avail
pgs: 260
Hey Dan,
Thanks for bringing this to our attention. Looks like it did get left
out. I just pushed the package and added a step to the release process
to make sure packages don't get skipped again like that.
- David
On 12/12/2018 11:03 AM, Dan van der Ster wrote:
> Hey Abhishek,
>
>
Hi Jeff
Many thanks for this! Looking forward to testing it out.
Could you elaborate a bit on why Nautilus is recommended for this set-up
please. Would attempting this with a Luminous cluster be a non-starter?
On Wed, 12 Dec 2018, 12:16 Jeff Layton (Sorry for the duplicate email to ganesha
cause some PG’s to not
>> have at least K size available as you only have 1 extra M.
>>
>> As per the error you can get your pool back online by setting min_size to 4.
>>
>> However this would only be a temp fix while you get the OSD back online /
>> rebuilt so you
Hi all,
I have a small 2-node cluster with 40 OSDs, using erasure coding 4+1
I lost osd38, and now I have 39 incomplete PGs.
---
PG_AVAILABILITY Reduced data availability: 39 pgs inactive, 39 pgs incomplete
pg 22.2 is incomplete, acting [19,33,10,8,29] (reducing pool media min_size
from 5
Is that one big xfs filesystem? Are you able to mount with krbd?
On Tue, 27 Nov 2018, 13:49 Vikas Rana Hi There,
>
> We are replicating a 100TB RBD image to DR site. Replication works fine.
>
> rbd --cluster cephdr mirror pool status nfs --verbose
>
> health: OK
>
> images: 1 total
>
> 1
For this the procedure is generally to stop the osd, flush the journal,
update the symlink on the osd to the new journal location, mkjournal, start
osd. You shouldn't need to do anything in the ceph.conf file.
On Thu, Nov 8, 2018 at 2:41 AM wrote:
> Hi all,
>
>
>
> I have been trying to
only using as much space as 2x replication.
On Thu, Nov 1, 2018 at 11:25 PM Wladimir Mutel wrote:
> David Turner wrote:
> > Yes, when creating an EC profile, it automatically creates a CRUSH rule
> > specific for that EC profile. You are also correct that 2+1 doesn't
>
My big question is that we've had a few of these releases this year that
are bugged and shouldn't be upgraded to... They don't have any release
notes or announcement and the only time this comes out is when users
finally ask about it weeks later. Why is this not proactively announced to
avoid a
to
update my omap backends.
On Mon, Nov 5, 2018 at 4:26 PM Pavan Rallabhandi <
prallabha...@walmartlabs.com> wrote:
> Not sure I understand that, but starting Luminous, the filestore omap
> backend is rocksdb by default.
>
>
>
> *From: *David Turner
> *Date: *Monday,
s feature was supported in Jewel starting 10.2.11, ref
> https://github.com/ceph/ceph/pull/18010
>
>
>
> I thought you mentioned you were using Luminous 12.2.4.
>
>
>
> *From: *David Turner
> *Date: *Friday, November 2, 2018 at 5:21 PM
>
>
> *To: *Pavan Rallabhandi
as well that can be used to set up the omap backend db.
On Fri, Nov 2, 2018, 4:26 PM Pavan Rallabhandi
wrote:
> It was Redhat versioned Jewel. But may be more relevantly, we are on
> Ubuntu unlike your case.
>
>
>
> *From: *David Turner
> *Date: *Friday, Novembe
.
>
> Thanks,
> -Pavan.
>
> From: David Turner
> Date: Monday, October 1, 2018 at 1:37 PM
> To: Pavan Rallabhandi
> Cc: ceph-users
> Subject: EXT: Re: [ceph-users] Any backfill in our cluster makes the
> cluster unusable and takes forever
>
> I tried m
Yes, when creating an EC profile, it automatically creates a CRUSH rule
specific for that EC profile. You are also correct that 2+1 doesn't really
have any resiliency built in. 2+2 would allow 1 node to go down while
still having your data accessible. It will use 2x data to raw as opposed
to
What version of qemu-img are you using? I found [1] this when poking
around on my qemu server when checking for rbd support. This version (note
it's proxmox) has rbd listed as a supported format.
[1]
# qemu-img -V; qemu-img --help|grep rbd
qemu-img version 2.11.2pve-qemu-kvm_2.11.2-1
Copyright
>From the balancer module's code for v 12.2.7 I noticed [1] these lines
which reference [2] these 2 config options for upmap. You might try using
more max iterations or a smaller max deviation to see if you can get a
better balance in your cluster. I would try to start with [3] these
ceph.keyring
>>
>> ---
>> Alex
>>
>> On Tue, Oct 30, 2018 at 4:48 AM David Turner
>> wrote:
>> >
>> > Set noout, reinstall the OS without going the OSDs (including any
>> journal partitions and maintaining any dmcrypt keys if you have
>
Set noout, reinstall the OS without going the OSDs (including any journal
partitions and maintaining any dmcrypt keys if you have encryption),
install ceph, make sure the ceph.conf file is correct,zip start OSDs, unset
noout once they're back up and in. All of the data the OSD needs to start
is on
min_size should be at least k+1 for EC. There are times to use k for
emergencies like you had. I would suggest seeing it back to 3 once your
back to healthy.
As far as why you needed to reduce min_size, my guess would be that
recovery would have happened as long as k copies were up. Were the PG's
Which version of Ceph are you running? Do you have any kernel clients? If
yes, can which version kernel? These questions are all leading to see if
you can enable the Luminous/Mimic mgr module balancer with upmap. If you
can, it is hands down the best way to balance your cluster.
On Sat, Oct 27,
If your had a specific location for the wal it would show up there. If
there is no entry for the wal, then it is using the same seeing as the db.
On Sun, Oct 28, 2018, 9:26 PM Robert Stanford
wrote:
>
> Mehmet: it doesn't look like wal is mentioned in the osd metadata. I see
> bluefs slow,
It is indeed adding a placement target and not removing it replacing the
pool. The get/put wouldn't be a rados or even ceph command, you would do it
through an s3 client.
On Fri, Oct 26, 2018, 9:38 AM Matthew Vernon wrote:
> Hi,
>
> On 26/10/2018 12:38, Alexandru Cucu wrote:
>
> > Have a look
Resharding a bucket won't affect the data in the bucket. After you change
the placement for a bucket, you could update where the data is by
re-writing all of the data in the bucket.
On Thu, Oct 25, 2018 at 8:48 AM Jacek Suchenia
wrote:
> Hi
>
> We have a bucket created with LocationConstraint
There are no tools to migrate in either direction between EC and Replica.
You can't even migrate an EC pool to a new EC profile.
With RGW you can create a new data pool and new objects will be written to
the new pool. If your objects have a lifecycle, then eventually you'll be
to the new pool
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
lization
> on the cluster than what's in the pools, the excess equal to about wal size
> * number of osds...
>
> On Mon, Oct 22, 2018 at 3:35 PM David Turner
> wrote:
>
>> My DB doesn't have a specific partition anywhere, but there's still a
>> symlink for it to t
nfiguration/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.db symlink points to that disk, right? There is however no wal
>> symlink?
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.
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 separat
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
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
wrote:
> Hi David,
>
> sorry for the slow response, we had a hell of a week at work.
>
> OK, so I had compression mode set to aggressive on some pools, but the
> global option was not changed, because I interpreted the documentation as
> "pool settings take precedence
2TB SSD.
> >
> > Log of osd.19 is here:
> > https://pastebin.com/raw/6DWwhS0A
> >
> > Am 13.10.2018 um 21:20 schrieb Stefan Priebe - Profihost AG:
> >> Hi David,
> >>
> >> i think this should be the problem - form a new log from today:
&
Not all pools need the same amount of PGs. When you get to so many pools
you want to start calculating how much data each pool will have. If 1 of
your pools will have 80% of your data in it, it should have 80% of your
PGs. The metadata pools for rgw likely won't need more than 8 or so PGs
each. If
Mgr and MDS do not use physical space on a disk. Mons do use the disk and
benefit from SSDs, but they write a lot of stuff all the time. Depending
why the SSDs aren't suitable for OSDs, they might not be suitable for mons
either.
On Mon, Oct 15, 2018, 7:16 AM ST Wong (ITSC) wrote:
> Hi all,
>
>
settings which you can see there about minimum ratios, blob
sizes, etc). To compress current data, you need to re-write it.
On Fri, Oct 12, 2018 at 10:41 AM Frank Schilder wrote:
> Hi David,
>
> thanks for your quick answer. When I look at both references, I see
> exactly the same comman
What do you want to use these for? "5 Year or 0.2 DWPD" is the durability
of this drive which is absolutely awful for most every use in Ceph.
Possibly if you're using these for data disks (not DB or WAL) and you plan
to have a more durable media to host the DB+WAL on... this could work. Or
if
The PGs per OSD does not change unless the OSDs are marked out. You have
noout set, so that doesn't change at all during this test. All of your PGs
peered quickly at the beginning and then were active+undersized the rest of
the time, you never had any blocked requests, and you always had
It's all of the settings that you found in your first email when you dumped
the configurations and such.
http://docs.ceph.com/docs/master/rados/configuration/bluestore-config-ref/#inline-compression
On Fri, Oct 12, 2018 at 7:36 AM Frank Schilder wrote:
> Hi David,
>
> thanks for your
83f2~1,d83f4~3,d83f8~3,d83fd~2,d8402~1,d8405~1,d8407~1,d840a~2,d840f~1,d8411~1,d8413~3,d8417~3,d841c~4,d8422~4,d8428~2,d842b~1,d842e~1,d8430~1,d8432~5,d843a~1,d843c~3,d8440~5,d8447~1,d844a~1,d844d~1,d844f~1,d8452~1,d8455~1,d8457~1,d8459~2,d845d~2,d8460~1,d8462~3,d8467~1,d8469~1,d846b~2,d846e~2,d8
My first guess is to ask what your crush rules are. `ceph osd crush rule
dump` along with `ceph osd pool ls detail` would be helpful. Also if you
have a `ceph status` output from a time where the VM RBDs aren't working
might explain something.
On Thu, Oct 11, 2018 at 1:12 PM Nils Fahldieck -
As a part of a repair is queuing a deep scrub. As soon as the repair part
is over the deep scrub continues until it is done.
On Thu, Oct 11, 2018, 12:26 PM Brett Chancellor
wrote:
> Does the "repair" function use the same rules as a deep scrub? I couldn't
> get one to kick off, until I
I have 4 other slack servers that I'm in for work and personal hobbies.
It's just easier for me to maintain one more slack server than have a
separate application for IRC.
On Thu, Oct 11, 2018, 11:02 AM John Spray wrote:
> On Thu, Oct 11, 2018 at 8:44 AM Marc Roos
> wrote:
> >
> >
> > Why
Not a resolution, but an idea that you've probably thought of. Disabling
logging on any affected OSDs (possibly just all of them) seems like a
needed step to be able to keep working with this cluster to finish the
upgrade and get it healthier.
On Wed, Oct 10, 2018 at 6:37 PM Wido den Hollander
I would like an invite to. drakonst...@gmail.com
On Wed, Sep 19, 2018 at 1:02 PM Gregory Farnum wrote:
> Done. :)
>
> On Tue, Sep 18, 2018 at 12:15 PM Alfredo Daniel Rezinovsky <
> alfredo.rezinov...@ingenieria.uncuyo.edu.ar> wrote:
>
>> Can anyone add me to this slack?
>>
>> with my email
There is a newer [1] feature to be able to set flags per OSD instead of
cluster wide. This way you can prevent a problem host from marking its
OSDs down while the rest ofthe cluster is capable of doing so. [2] These
commands ought to clear up your status.
[1]
I know that it existed, but I've never bothered using it. In applications
like Python where you can get a different reaction by interacting with it
line by line and setting up an environment it is very helpful. Ceph,
however, doesn't have any such environment variables that would make this
more
I would suggest trying to delete the bucket using radosgw-admin. If you
can't get that to work, then I would go towards deleting the actual RADOS
objects. There are a few threads on the ML that talk about manually
deleting a bucket.
On Thu, Sep 20, 2018 at 2:04 PM Sean Purdy wrote:
> Hi,
>
>
When I've tested compression before there are 2 places you need to
configure compression. On the OSDs in the configuration settings that you
mentioned, but also on the [1] pools themselves. If you have the
compression mode on the pools set to none, then it doesn't matter what the
OSDs
Can you outline the process you're using to access the REST API? It's hard
to troubleshoot this without knowing how you were trying to do this.
On Mon, Sep 17, 2018 at 7:09 PM Michael Schäfer
wrote:
> Hi,
>
> We have a problem with the radosgw using the S3 REST API.
> Trying to create a new
Have you looked at your Garbage Collection. I would guess that your GC is
behind and that radosgw-admin is accounting for that space knowing that it
hasn't been freed up yet, whiles 3cmd doesn't see it since it no longer
shows in the listing.
On Tue, Sep 18, 2018 at 4:45 AM Luis Periquito
Same issue here, Gmail user, member of different lists but only get
disabled on ceph-users. Happens about once a month but had three in Sept.
On Sat, 6 Oct 2018, 18:28 Janne Johansson, wrote:
> Den lör 6 okt. 2018 kl 15:06 skrev Elias Abacioglu
> :
> >
> > Hi,
> >
> > I'm bumping this old
It really seems to be something with RocksDB on centOS. I still think
> you can try removing “compression=kNoCompression” from the
> filestore_rocksdb_options And/Or check if rocksdb is expecting snappy to be
> enabled.
>
> Thanks,
> -Pavan.
>
> From: David Turner
r clients with only
> 1Gb nic will go through 140.109.0.0 (1Gb LAN) to ask mon or to read/write
> to osds. This is why my osds also have 1Gb and 10Gb nics with 140.109.0.0
> and 10.32.0.0 networking respectively.
>
> Cheers
> Joshua
>
> On Sun, Sep 30, 2018 at 12:09 PM
The cluster/private network is only used by the OSDs. Nothing else in ceph
or its clients communicate using it. Everything other than osd to osd
communication uses the public network. That includes the MONs, MDSs,
clients, and anything other than an osd talking to an osd. Nothing else
other than
ssion to be enabled, can you try
> removing “compression=kNoCompression” from the filestore_rocksdb_options?
> And/or you might want to check if rocksdb is expecting snappy to be enabled.
>
> From: David Turner
> Date: Tuesday, September 18, 2018 at 6:01 PM
> To: Pavan Rallabhand
hutting
> down a mon to see if a single one was the problem, but they keep electing no
> matter the mix of them that are up. Part of it feels like a networking
> problem but I haven't been able to find a culprit yet as everything was
> working normally before starting the upgrade. Other t
No, Ceph Mimic will not be available for Ubuntu Trusty 14.04. That release
is almost 4.5 years old now, you should start planning towards an OS
upgrade.
On Wed, Sep 19, 2018 at 8:54 AM Jakub Jaszewski
wrote:
> Hi Cephers,
>
> Any plans for Ceph Mimic packages for Ubuntu Trusty? I found only
>
>
> But the stack trace didn’t hint as if the superblock on the OSD is
> still considering the omap backend to be leveldb and to do with the
> compression.
>
> Thanks,
> -Pavan.
>
> From: David Turner
> Date: Tuesday, September 18, 2018 at 5:07 PM
&g
,
> -Pavan.
>
> From: ceph-users on behalf of David
> Turner
> Date: Tuesday, September 18, 2018 at 4:09 PM
> To: ceph-users
> Subject: EXT: [ceph-users] Any backfill in our cluster makes the cluster
> unusable and takes forever
>
> I've finally learned enough ab
I've finally learned enough about the OSD backend track down this issue to
what I believe is the root cause. LevelDB compaction is the common thread
every time we move data around our cluster. I've ruled out PG subfolder
splitting, EC doesn't seem to be the root cause of this, and it is cluster
It's odd to me because this feels like the opposite direction of the rest
of Ceph. Making management and operating Ceph simpler and easier. Requiring
fast OS upgrades on dot releases of Ceph versions is not that direction at
all.
On Fri, Sep 14, 2018, 9:25 AM David Turner wrote:
> Release da
Release dates
RHEL 7.4 - July 2017
Luminous 12.2.0 - August 2017
CentOS 7.4 - September 2017
RHEL 7.5 - April 2018
CentOS 7.5 - May 2018
Mimic 13.2.0 - June 2018
In the world of sysadmins it takes time to let new releases/OS's simmer
before beginning to test them let alone upgrading to them. It
I have a stage cluster with 4 HDDs and an SSD in each host. I have an EC
profile that specifically chooses HDDs for placement. Also several Replica
pools that write to either HDD or SSD. This has all worked well for a
while. When I updated the Tunables to Jewel on the cluster, all of a
sudden
Sorry, I was wrong that it was you. I just double checked. But there is a
new thread as of this morning about this topic where someone is running
benchmark tests with numbers titled "Benchmark does not show gains with DB
on SSD".
On Wed, Sep 12, 2018 at 12:20 PM David Turner wro
You already have a thread talking about benchmarking the addition of WAL
and DB partitions to an OSD. Why are you creating a new one about the
exact same thing? As with everything, the performance increase isn't even
solely answerable by which drives you have, there are a lot of factors that
If you're writes are small enough (64k or smaller) they're being placed on
the WAL device regardless of where your DB is. If you change your testing
to use larger writes you should see a difference by adding the DB.
Please note that the community has never recommended using less than 120GB
DB
ceph balancer status
ceph config-key dump | grep balancer
ceph osd dump | grep min_compat_client
ceph osd crush dump | grep straw
ceph osd crush dump | grep profile
ceph features
You didn't mention it, but based on your error and my experiences over the
last week getting the balancer working,
while allowing CentOS 7.5 clients map RBDs?
On Mon, Sep 10, 2018 at 1:33 PM Ilya Dryomov wrote:
> On Mon, Sep 10, 2018 at 7:19 PM David Turner
> wrote:
> >
> > I haven't found any mention of this on the ML and Google's results are
> all about compiling your own kernel
I haven't found any mention of this on the ML and Google's results are all
about compiling your own kernel to use NBD on CentOS. Is everyone that's
using rbd-nbd on CentOS honestly compiling their own kernels for the
clients? This feels like something that shouldn't be necessary anymore.
I would
Yes, migrating to 12.2.8 is fine. Migrating to not use the cache tier is as
simple as changing the ec pool mode to allow EC over writes, changing the
cache tier mode to forward, flushing the tier, and removing it. Basically
once you have EC over writes just follow the steps in the docs for
You can indeed have multiple types of pools on the same disks. Go ahead and
put the non-ec pool with a replicated ruleset on the HDDs with the EC data
pool. I believe your correct that the non-ec pool gets cleared out when the
upload is complete and the file is flushed to EC.
On Sun, Sep 9, 2018,
The problem is with the kernel pagecache. If that is still shared in a
containerized environment with the OSDs in containers and RBDs which are
married on The node outside of containers, then it is indeed still a
problem. I would guess that's the case, but I do not know for certain.
Using rbd-nbd
What osd/mon/etc config settings do you have that are not default? It might
be worth utilizing nodown to stop osds from marking each other down and
finish the upgrade to be able to set the minimum osd version to mimic. Stop
the osds in a node, manually mark them down, start them back up in mimic.
I tested running VMs on EC back in Hammer. The performance was just bad. I
didn't even need much io, but even performing standard maintenance was
annoying enough that I abandoned the idea. I didn't really try to tweak
settings to make it work and I only had a 3 node cluster running 2+1. I did
use
ther necessary functions) so you can't disable it on the
> server.
> -Greg
>
> On Fri, Sep 7, 2018 at 11:48 AM David Turner
> wrote:
>
>> Is it be possible to disable this feature? Very few filesystems
>> calculate the size of its folder's contents. I know I enjoy
e
> tree to enable good differential backups. Not sure what the status of that
> is.
> -Greg
>
> On Fri, Sep 7, 2018 at 11:06 AM David Turner
> wrote:
>
>> We have an existing workflow that we've moved from one server sharing a
>> local disk via NFS to secondary ser
We have an existing workflow that we've moved from one server sharing a
local disk via NFS to secondary servers to all of them mounting CephFS.
The primary server runs a script similar to [1] this, but since we've moved
it into CephFS, we get [2] this error. We added the sync in there to try
to
They mentioned that they were going to send the slides to everyone that had
their badges scanned at the conference. I haven't seen that email come out
yet, though.
On Thu, Sep 6, 2018 at 4:14 PM Gregory Farnum wrote:
> Unfortunately I don't believe anybody collected the slide files, so they
>
The official ceph documentation recommendations for a db partition for a
4TB bluestore osd would be 160GB each.
Samsung Evo Pro is not an Enterprise class SSD. A quick search of the ML
will allow which SSDs people are using.
As was already suggested, the better option is an HBA as opposed to a
The magic sauce to get Filestore OSDs to start on a node reboot is to make
sure that all of your udev magic is correct. In particular you need to
have the correct UUID set for all partitions. I haven't dealt with it in a
long time, but I've written up a few good ML responses about it.
On Tue,
-
> > * bluestore: set correctly shard for existed Collection (issue#24761,
> pr#22860, Jianpeng Ma)
> > * build/ops: Boost system library is no longer required to compile and
> link example librados program (issue#25054, pr#23202, Nathan Cutler)
> > * build/ops: Bring b
preventing your cluster from being poorly balanced.
On Mon, Sep 3, 2018 at 12:08 PM David C wrote:
> Hi Marc
>
> I like that approach although I think I'd go in smaller weight increments.
>
> Still a bit confused by the behaviour I'm seeing, it looks like I've got
> things weighted c
I was confused what could be causing this until Janne's email. I think
they're correct that the cluster is preventing pool creation due to too
many PGs per OSD. Double check how many PGs you have in each pool and what
your defaults are for that.
On Mon, Sep 3, 2018 at 7:19 AM Janne Johansson
Are you planning on using bluestore or filestore? The settings for
filestore haven't changed. If you're planning to use bluestore there is a
lot of documentation in the ceph docs as well as a wide history of
questions like this on the ML.
On Mon, Sep 3, 2018 at 5:24 AM M Ranga Swami Reddy
ph osd crush reweight osd.28 2
> sudo -u ceph ceph osd crush reweight osd.29 2
>
> Etc etc
>
>
> -Original Message-
> From: David C [mailto:dcsysengin...@gmail.com]
> Sent: maandag 3 september 2018 14:34
> To: ceph-users
> Subject: [ceph-users] Luminous
this one with a
lower crush weight and then continue adding the drives and then eventually
even out the crush weights?
Thanks
David
___
ceph-users mailing list
ceph-users@lists.ceph.com
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
if you delay the
"...require-osd-release luminous" for whatever reason as it appears to
leave you with no backfillfull limit
Still having a bit of an issue with new OSDs over filling but will start a
new thread for that
Cheers,
On Thu, Aug 30, 2018 at 10:34 PM David Turner wrote:
>
On Sun, Sep 2, 2018 at 1:31 PM Alfredo Deza wrote:
>
> On Sun, Sep 2, 2018 at 12:00 PM, David Wahler wrote:
> > Ah, ceph-volume.log pointed out the actual problem:
> >
> > RuntimeError: Cannot use device (/dev/storage/bluestore). A vg/lv path
> > or an existing de
Agreed on not going the disks until your cluster is healthy again. Making
them out and seeing how healthy you can get in the meantime is a good idea.
On Sun, Sep 2, 2018, 1:18 PM Ronny Aasen wrote:
> On 02.09.2018 17:12, Lee wrote:
> > Should I just out the OSD's first or completely zap them
the ceph-deploy logs are a bit confusing. I submitted a
PR to add a brief note to the quick-start guide, in case anyone else
makes the same mistake: https://github.com/ceph/ceph/pull/23879
Thanks for the assistance!
-- David
On Sun, Sep 2, 2018 at 7:44 AM Alfredo Deza wrote:
>
> There shoul
astien-han.fr/blog/2014/11/27/ceph-recover-osds-after-ssd-journal-failure/
>
> Which they all started without a problem.
>
>
> On Sun, 2 Sep 2018 at 15:43, David Turner wrote:
>
>> It looks like osds on the first failed node are having problems. What
>> commands did
101 - 200 of 1451 matches
Mail list logo
