On Tue, 11 Jun 2019 at 14:46, Sakirnth Nagarasa
wrote:
> On 6/7/19 3:35 PM, Jason Dillaman wrote:
[...]
> > Can you run "rbd rm --log-to-stderr=true --debug-rbd=20
> > ${POOLNAME}/${IMAGE}" and provide the logs via pastebin.com?
> >
> >> Cheers,
> >> Sakirnth
>
> It is not necessary anymore the
On Thu, 6 Jun 2019 at 03:01, Josh Haft wrote:
>
> Hi everyone,
>
> On my 13.2.5 cluster, I recently enabled the ceph balancer module in
> crush-compat mode.
Why did you choose compat mode? Don't you want to try another one instead?
--
End of message. Next message?
On Sat, 8 Jun 2019 at 04:35, Sergei Genchev wrote:
>
> Hi,
> My OSD processes are constantly getting killed by OOM killer. My
> cluster has 5 servers, each with 18 spinning disks, running 18 OSD
> daemons in 48GB of memory.
> I was trying to limit OSD cache, according to
>
What is your experience?
Does it make sense to use it -- is it solid enough or beta quality
rather (both in terms of stability and performance)?
I've read it was more or less packaged to work with RHEL. Does it hold
true still?
What's the best way to install it on, say, CentOS or Debian/Ubuntu?
On Wed, 22 May 2019 at 20:32, Torben Hørup wrote:
>
> Which states are all these connections in ?
>
> ss -tn
That set of the args won't display anything but ESTAB-lished conn-s..
One typically needs `-atn` instead.
--
End of message. Next message?
On Tue, 21 May 2019 at 19:32, Yoann Moulin wrote:
>
> >> I am doing some tests with Nautilus and cephfs on erasure coding pool.
[...]
> > http://lists.ceph.com/pipermail/ceph-users-ceph.com/2019-May/034867.html
>
> Oh thanks, I missed that thread, make sense. I agree with some comment that
> it
On Fri, 3 May 2019 at 22:46, Robert Sander wrote:
> The cluster spans 2 rooms
...
> The failure domain would be the room level
...
> Is that even possible with erasure coding?
Sure deal but you'd need slightly more rooms then. For e. g., minimal
EC(2, 1) means (2 + 1) rooms.
--
End of message.
On Fri, 3 May 2019 at 21:39, Mark Nelson wrote:
[...]
> > [osd]
> > ...
> > bluestore_allocator = bitmap
> > bluefs_allocator = bitmap
> >
> > I would restart the nodes one by one and see, what happens.
>
> If you are using 12.2.11 you likely still have the old bitmap allocator
Would those
On Fri, 3 May 2019 at 13:38, Denny Fuchs wrote:
[...]
> If I understand correct: I should try to set bitmap allocator
That's among one of the options I mentioned.
Another one was to try using jemalloc (re-read my emails).
> [osd]
> ...
> bluestore_allocator = bitmap
> bluefs_allocator = bitmap
On Fri, 3 May 2019 at 05:12, Mark Nelson wrote:
[...]
> > -- https://www.kernel.org/doc/Documentation/vm/transhuge.txt
>
> Why are you quoting the description for the madvise setting when that's
> clearly not what was set in the case I just showed you?
Similarly why(?) are you telling us it must
On Fri, 3 May 2019 at 01:29, Mark Nelson wrote:
> On 5/2/19 11:46 AM, Igor Podlesny wrote:
> > On Thu, 2 May 2019 at 05:02, Mark Nelson wrote:
> > [...]
> >> FWIW, if you still have an OSD up with tcmalloc, it's probably worth
> >> looking at the heap stats to se
On Thu, 2 May 2019 at 05:02, Mark Nelson wrote:
[...]
> FWIW, if you still have an OSD up with tcmalloc, it's probably worth
> looking at the heap stats to see how much memory tcmalloc thinks it's
> allocated vs how much RSS memory is being used by the process. It's
> quite possible that there
On Tue, 30 Apr 2019 at 20:56, Igor Podlesny wrote:
> On Tue, 30 Apr 2019 at 19:10, Denny Fuchs wrote:
> [..]
> > Any suggestions ?
>
> -- Try different allocator.
Ah, BTW, except memory allocator there's another option: recently
backported bitmap allocator.
Igor Fedoto
On Wed, 1 May 2019 at 01:58, Dan van der Ster wrote:
> On Tue, Apr 30, 2019 at 8:26 PM Igor Podlesny wrote:
[...]
> All of the clients need to be luminous our newer:
>
> # ceph osd set-require-min-compat-client luminous
>
> You need to enable the module:
>
> # ceph mg
On Wed, 1 May 2019 at 01:26, Igor Podlesny wrote:
> On Wed, 1 May 2019 at 01:01, Dan van der Ster wrote:
> >> > The upmap balancer in v12.2.12 works really well... Perfectly uniform on
> >> > our clusters.
> >>
> >> mode upmap ?
> >
> > y
On Wed, 1 May 2019 at 01:26, Jack wrote:
> If those pools are useless, you can:
> - drop them
As Dan pointed out it's unlikely of having any effect.
The thing is imbalance is a "property" of a pool, I'd suppose that
most often -- is the most loaded one (or of a few most loaded ones).
Not that
On Wed, 1 May 2019 at 01:01, Dan van der Ster wrote:
>> > The upmap balancer in v12.2.12 works really well... Perfectly uniform on
>> > our clusters.
>>
>> mode upmap ?
>
> yes, mgr balancer, mode upmap.
I see. Was it a matter of just:
1) ceph balancer mode upmap
2) ceph balancer on
or were
On Wed, 1 May 2019 at 00:24, Dan van der Ster wrote:
>
> The upmap balancer in v12.2.12 works really well... Perfectly uniform on our
> clusters.
>
> .. Dan
mode upmap ?
--
End of message. Next message?
___
ceph-users mailing list
On Tue, 30 Apr 2019 at 19:10, Denny Fuchs wrote:
[..]
> Any suggestions ?
-- Try different allocator.
In Proxmox 4 they by default had this in /etc/default/ceph {{
## use jemalloc instead of tcmalloc
#
# jemalloc is generally faster for small IO workloads and when
# ceph-osd is backed by SSDs.
On Tue, 30 Apr 2019 at 19:11, Adrien Gillard
wrote:
> On Tue, Apr 30, 2019 at 10:06 AM Igor Podlesny wrote:
> >
> > On Tue, 30 Apr 2019 at 04:13, Adrien Gillard
> wrote:
> > > I would add that the use of cache tiering, though still possible, is
> not recommend
On Mon, 15 Apr 2019 at 19:40, Wido den Hollander wrote:
>
> Hi,
>
> With the release of 12.2.12 the bitmap allocator for BlueStore is now
> available under Mimic and Luminous.
>
> [osd]
> bluestore_allocator = bitmap
> bluefs_allocator = bitmap
Hi!
Have you tried this? :)
--
End of message.
On Tue, 30 Apr 2019 at 04:13, Adrien Gillard wrote:
> I would add that the use of cache tiering, though still possible, is not
> recommended
It lacks references. CEPH docs I gave links to didn't say so.
> comes with its own challenges.
It's challenging for some to not over-quote when
On Mon, 29 Apr 2019 at 16:19, Rainer Krienke wrote:
[...]
> - Do I still (nautilus) need two pools for EC based RBD images, one EC
> data pool and a second replicated pool for metadatata?
The answer is given at
On Mon, 29 Apr 2019 at 16:37, Burkhard Linke
wrote:
> On 4/29/19 11:19 AM, Rainer Krienke wrote:
[...]
> > - I also thought about the different k+m settings for a EC pool, for
> > example k=4, m=2 compared to k=8 and m=2. Both settings allow for two
> > OSDs to fail without any data loss, but I
On Mon, 29 Apr 2019 at 15:13, Eugen Block wrote:
>
> Sure there is:
>
> ceph pg ls-by-osd
Thank you Eugen, I overlooked it somehow :)
--
End of message. Next message?
___
ceph-users mailing list
ceph-users@lists.ceph.com
Or is there no direct way to accomplish that?
What workarounds can be used then?
--
End of message. Next message?
___
ceph-users mailing list
ceph-users@lists.ceph.com
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
Say, some nodes have OSDs that are 1.5 times bigger, than other nodes
have, meanwhile weights of all the nodes in question is almost equal
(due having different number of OSDs obviously)
--
End of message. Next message?
___
ceph-users mailing list
On Sun, 28 Apr 2019 at 16:14, Paul Emmerich wrote:
> Use k+m for PG calculation, that value also shows up as "erasure size"
> in ceph osd pool ls detail
So does it mean that for PG calculation those 2 pools are equivalent:
1) EC(4, 2)
2) replicated, size 6
? Sounds weird to be honest.
For replicated pools (w/o rounding to nearest power of two) overall
PGs number is calculated so:
Pools_PGs = 100 * (OSDs / Pool_Size),
where
100 -- target number of PGs per single OSD related to that pool,
Pool_Size -- factor showing how much raw storage would in fact be
used to
I remember seeing reports in regards but it's being a while now.
Can anyone tell?
--
End of message. Next message?
___
ceph-users mailing list
ceph-users@lists.ceph.com
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
On Tue, 16 Apr 2019 at 17:05, Paul Emmerich wrote:
>
> No, the problem is that a storage system should never tell a client
> that it has written data if it cannot guarantee that the data is still
> there if one device fails.
[...]
Ah, now I got your point.
Anyways, it should be users' choice
On Tue, 16 Apr 2019 at 16:52, Paul Emmerich wrote:
> On Tue, Apr 16, 2019 at 11:50 AM Igor Podlesny wrote:
> > On Tue, 16 Apr 2019 at 14:46, Paul Emmerich wrote:
[...]
> > Looked at it, didn't see any explanation of your point of view. If
> > there're 2 active data i
On Tue, 16 Apr 2019 at 14:46, Paul Emmerich wrote:
> Sorry, I just realized I didn't answer your original question.
[...]
No problemo. -- I've figured out the answer to my own question earlier anyways.
And actually gave a hint today
On Tue, 16 Apr 2019 at 06:43, Mark Schouten wrote:
[...]
> So where is the rest of the free space? :X
Makes sense to see:
sudo ceph osd df tree
--
End of message. Next message?
___
ceph-users mailing list
ceph-users@lists.ceph.com
And as to min_size choice -- since you've replied exactly to that part
of mine message only.
On Sat, 13 Apr 2019 at 06:54, Paul Emmerich wrote:
> On Fri, Apr 12, 2019 at 9:30 PM Igor Podlesny wrote:
> > For e. g., an EC pool with default profile (2, 1) has bogus "sizing"
On Sat, 13 Apr 2019 at 06:54, Paul Emmerich wrote:
>
> Please don't use an EC pool with 2+1, that configuration makes no sense.
That's too much of an irony given that (2, 1) is default EC profile,
described in CEPH documentation in addition.
> min_size 3 is the default for that pool, yes. That
For e. g., an EC pool with default profile (2, 1) has bogus "sizing"
params (size=3, min_size=3).
Min. size 3 is wrong as far as I know and it's been fixed in fresh
releases (but not in Luminous).
But besides that it looks like pool usage isn't calculated according
to EC overhead but as if it was
It's wide known that some filesystems (well, ok -- 2 of them: ZFS and
Btrfs) detect bit rot on any read request, although, of course an
admin can initiate "whole platter" scrubbing.
Before Bluestore CEPH could provide only "on demand" detection. I
don't take into consideration imaginary setups
38 matches
Mail list logo
