On Sat, Oct 22, 2016 at 8:27 AM, fridifree wrote:
> Hi,
>
> What is the ceph tunables? how it affects the cluster?
You can read more about CRUSH tunables at [1], but tunables aren't in
play here - it's just the subject of that email.
> I upgrade my kernel I do not understand why I have to disabl
On Fri, Oct 21, 2016 at 9:31 PM, Steffen Weißgerber
wrote:
> Hello,
>
> we're running a 6 node ceph cluster with 3 mons on Ubuntu (14.04.4).
>
> Sometimes it happen's that the mon services die and have to restarted
> manually.
>
> To have reliable service restarts I normally use D.J. Bernsteins de
Hi, everyone.
I'm trying to read the source code that boots an OSD instance, and I find
something really overwhelms me.
In the OSD::init() method, it read the OSDSuperblock by calling
OSD::read_superblock(), and the it tried to get the "current" map : "osdmap =
get_map(superblock.current_epoch
Hi,
The 2.0 release notes for Red Hat Ceph Storage deprecate cache tiering.
What does this mean for Jewel and especially going forward?
Can someone shed some light why cache tiering is not meeting the original
expectations technically?
Thanks,
Zoltan
___
The osd needs to know where it thought data was, in particular so it knows what
it has. Then it gets the current map so it knows who to talk to so it can catch
back up.
Sent from my iPhone
On Oct 22, 2016, at 7:12 AM, xxhdx1985126
mailto:xxhdx1985...@163.com>> wrote:
Hi, everyone.
I'm trying
Title: 缃戞槗閭
Sorry, sir. I don't quite follow you. I agree that the osds must get the current map to know who to contact so it can catch up. But it looks to me that the osd is getting the current map through get_map(superblock.current_epoch) in which the variable superblock.current_epoch is read f
Title: 缃戞槗閭
Sorry, sir. I don't quite follow you. I agree that the osds must get the current map to know who to contact so it can catch up. But it looks to me that the osd is getting the current map through get_map(superblock.current_epoch) in which the content of the variable superblock.current_
