On Thu, Nov 30, 2017 at 2:08 AM, Jens-U. Mozdzen wrote:
> Hi *,
>
> while tracking down a different performance issue with CephFS (creating tar
> balls from CephFS-based directories takes multiple times as long as when
> backing up the same data from local disks, i.e. 56 hours instead of 7), we
>
> Op 29 november 2017 om 14:56 schreef Jason Dillaman :
>
>
> We experienced this problem in the past on older (pre-Jewel) releases
> where a PG split that affected the RBD header object would result in
> the watch getting lost by librados. Any chance you know if the
> affected RBD header object
Hi,
We've a problem to delete a snapshot. There was a child image of the
snapshot, but the child image was flatten. And now the snapshot still
"think" it has children, and can not be deleted.
Snapshot and children:
$ rbd snap ls volumes/volume-49ccf5a6-4c17-434a-a087-f04acef978ef
SNAPID NAME
I've just did ceph upgrade jewel -> luminous and am facing the same case...
# EC profile
crush-failure-domain=host
crush-root=default
jerasure-per-chunk-alignment=false
k=3
m=2
plugin=jerasure
technique=reed_sol_van
w=8
5 hosts in the cluster and I run systemctl stop ceph.target on one of them
so
On Tue, Nov 28, 2017 at 10:39:31AM -0800, Vasu Kulkarni wrote:
> On Tue, Nov 28, 2017 at 9:22 AM, David Turner wrote:
> > Isn't marking something as deprecated meaning that there is a better option
> > that we want you to use and you should switch to it sooner than later? I
> > don't understand ho
On Thu, Nov 30, 2017 at 6:31 AM, Fabian Grünbichler
wrote:
> On Tue, Nov 28, 2017 at 10:39:31AM -0800, Vasu Kulkarni wrote:
>> On Tue, Nov 28, 2017 at 9:22 AM, David Turner wrote:
>> > Isn't marking something as deprecated meaning that there is a better option
>> > that we want you to use and you
On Thu, Nov 30, 2017 at 07:04:33AM -0500, Alfredo Deza wrote:
> On Thu, Nov 30, 2017 at 6:31 AM, Fabian Grünbichler
> wrote:
> > On Tue, Nov 28, 2017 at 10:39:31AM -0800, Vasu Kulkarni wrote:
> >> On Tue, Nov 28, 2017 at 9:22 AM, David Turner
> >> wrote:
> >> > Isn't marking something as depreca
On Thu, Nov 30, 2017 at 4:00 AM, Wido den Hollander wrote:
>
>> Op 29 november 2017 om 14:56 schreef Jason Dillaman :
>>
>>
>> We experienced this problem in the past on older (pre-Jewel) releases
>> where a PG split that affected the RBD header object would result in
>> the watch getting lost by
On 11/30/17 14:04, Fabian Grünbichler wrote:
> point is - you should not purposefully attempt to annoy users and/or
> downstreams by changing behaviour in the middle of an LTS release cycle,
exactly. upgrading the patch level (x.y.z to x.y.z+1) should imho never
introduce a behaviour-change, regar
active+clean+remapped is not a healthy state for a PG. If it actually we're
going to a new osd it would say backfill+wait or backfilling and eventually
would get back to active+clean.
I'm not certain what the active+clean+remapped state means. Perhaps a PG
query, PG dump, etc can give more insight
This doesn't answer your question, but maybe nudges you in a different
direction. CephFS seams like the much better solution for what you're
doing. You linked a 5 year old blog post. CephFS was not a stable
technology at the time, but it's an excellent method to share a network FS
to multiple clien
> Op 30 november 2017 om 14:19 schreef Jason Dillaman :
>
>
> On Thu, Nov 30, 2017 at 4:00 AM, Wido den Hollander wrote:
> >
> >> Op 29 november 2017 om 14:56 schreef Jason Dillaman :
> >>
> >>
> >> We experienced this problem in the past on older (pre-Jewel) releases
> >> where a PG split that
As per your ceph status it seems that you have 19 pools, all of them are
erasure coded as 3+2?
It seems that when you taken the node offline ceph could move some of
the PGs to other nodes (it seems that that one or more pools does not
require all 5 osds to be healty. Maybe they are replicated,
Thanks all for your feedback on deprecating ceph-disk, we are very
excited to be able to move forwards on a much more robust tool and
process for deploying and handling activation of OSDs, removing the
dependency on UDEV which has been a tremendous source of constant
issues.
Initially (see "killin
how quickly are you planning to cut 12.2.3?
On Thu, Nov 30, 2017 at 4:25 PM, Alfredo Deza wrote:
> Thanks all for your feedback on deprecating ceph-disk, we are very
> excited to be able to move forwards on a much more robust tool and
> process for deploying and handling activation of OSDs, remo
How quickly are you planning to cut 12.2.3?
On Thu, Nov 30, 2017 at 4:25 PM, Alfredo Deza wrote:
> Thanks all for your feedback on deprecating ceph-disk, we are very
> excited to be able to move forwards on a much more robust tool and
> process for deploying and handling activation of OSDs, remov
We're talking about dropping trusty support for mimic due to the old
compiler (incomplete C++11), hassle of using an updated toolchain, general
desire to stop supporting old stuff, and lack of user objections to
dropping it in the next release.
We would continue to build trusty packages for lum
That's correct, IPoIB for the backend (already configured the irq
affinity), and 10GbE on the frontend. I would love to try rdma but like
you said is not stable for production, so I think I'll have to wait for
that. Yeah, the thing is that it's not my decision to go for 50GbE or
100GbE... :( so..
Hey Cephers,
This is just a friendly reminder that the next Ceph Developer Montly
meeting is coming up:
http://wiki.ceph.com/Planning
If you have work that you're doing that it a feature work, significant
backports, or anything you would like to discuss with the core team,
please add it to the
On 11/30/2017 12:21 PM, Sage Weil wrote:
> We're talking about dropping trusty support for mimic due to the old
> compiler (incomplete C++11), hassle of using an updated toolchain, general
> desire to stop supporting old stuff, and lack of user objections to
> dropping it in the next release.
>
Hi,
we currently do not understand how we got into this situation, nevertheless
we have a set of rbd images which has the same SNAPID in the same pool.
kjetil@sc2-r10-u09:~$ rbd snap ls _qa-staging_foo_partial_db
SNAPID NAME SIZE
478104 2017-11-29.001 2 MB
kjetil@sc2-r10-u09:~$
Hi all,
today I tested adding SSD cache tier to pool.
Everything worked, but when I tried to remove it and run
rados -p hot-pool cache-flush-evict-all
I got
rbd_data.9c000238e1f29.
failed to flush /rbd_data.9c000238e1f29.: (2) No such
file or directory
On Tue, Nov 7, 2017 at 3:12 AM, Leonardo Vaz wrote:
> On Mon, Nov 06, 2017 at 09:54:41PM +0800, kefu chai wrote:
>> On Thu, Oct 5, 2017 at 12:16 AM, Leonardo Vaz wrote:
>> > On Wed, Oct 04, 2017 at 03:02:09AM -0300, Leonardo Vaz wrote:
>> >> On Thu, Sep 28, 2017 at 12:08:00AM -0300, Leonardo Vaz
On Thu, Nov 30, 2017 at 5:30 PM, nokia ceph wrote:
> Hello,
>
> I'm following
> http://docs.ceph.com/docs/master/ceph-volume/lvm/prepare/#ceph-volume-lvm-prepare-bluestore
> to create new OSD's.
>
> I took the latest branch from https://shaman.ceph.com/repos/ceph/luminous/
>
> # ceph -v
> ceph v
24 matches
Mail list logo
