date:20161022

Re: [ceph-users] Question about OSDSuperblock

2016-10-22 Thread xxhdx1985126

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_epoch is read from the disk by OSD::read_superblock and has't been updated by a monitor at boot time, which means it is not the real curent epoch but an old one. How can OSD get the current map using an old epoch?

On xxhdx1985126 , Oct 23, 2016 3:13 AM wrote:

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 from the disk by OSD::read_superblock at boot time and has't been updated by a monitor, which means it is not the real curent epoch. How can OSD get the current map using an old epoch?

Sent from my Mi phoneOn David Turner , Oct 23, 2016 12:34 AM wrote:

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 wrote:

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)". Then OSD uses this osdmap to calculate the acting and up set of each pg.聽
I really don't understand this! Since the OSDSuperblock is read from the disk, the superblock.current_epoch should be an old epoch which is recorded by the last OSD instance that run on this directory. Why use an old "current_epoch" to calculate the acting
and up set of each pg?

Please help me, thank you:-)

聽

If you are not the intended recipient of this message or received it erroneously, please notify the sender and delete it, together with any attachments, and be advised that any dissemination or copying of this
message is prohibited.

___
ceph-users mailing list
ceph-users@lists.ceph.com
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com

Re: [ceph-users] Question about OSDSuperblock

2016-10-22 Thread xxhdx1985126

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 from the disk by OSD::read_superblock at boot time and has't been updated by a monitor, which means it is not the real curent epoch. How can OSD get the current map using an old epoch?

Sent from my Mi phoneOn David Turner , Oct 23, 2016 12:34 AM wrote:

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 wrote:

Hi, everyone.

Please help me, thank you:-)

聽

___
ceph-users mailing list
ceph-users@lists.ceph.com
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com

Re: [ceph-users] Question about OSDSuperblock

2016-10-22 Thread David Turner

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 
> wrote:

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)". Then OSD uses this osdmap to calculate the 
acting and up set of each pg.
I really don't understand this! Since the OSDSuperblock is read from the disk, 
the superblock.current_epoch should be an old epoch which is recorded by the 
last OSD instance that run on this directory. Why use an old "current_epoch" to 
calculate the acting and up set of each pg?

Please help me, thank you:-)







[cid:image15424c.JPG@ef7d796d.48843c49]   David 
Turner | Cloud Operations Engineer | StorageCraft Technology 
Corporation
380 Data Drive Suite 300 | Draper | Utah | 84020
Office: 801.871.2760 | Mobile: 385.224.2943



If you are not the intended recipient of this message or received it 
erroneously, please notify the sender and delete it, together with any 
attachments, and be advised that any dissemination or copying of this message 
is prohibited.



___
ceph-users mailing list
ceph-users@lists.ceph.com
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
___
ceph-users mailing list
ceph-users@lists.ceph.com
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com

[ceph-users] cache tiering deprecated in RHCS 2.0

2016-10-22 Thread Zoltan Arnold Nagy

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
___
ceph-users mailing list
ceph-users@lists.ceph.com
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com

[ceph-users] Question about OSDSuperblock

2016-10-22 Thread xxhdx1985126

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)". Then OSD uses this osdmap to calculate the 
acting and up set of each pg. 
I really don't understand this! Since the OSDSuperblock is read from the disk, 
the superblock.current_epoch should be an old epoch which is recorded by the 
last OSD instance that run on this directory. Why use an old "current_epoch" to 
calculate the acting and up set of each pg?


Please help me, thank you:-)___
ceph-users mailing list
ceph-users@lists.ceph.com
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com

Re: [ceph-users] reliable monitor restarts

2016-10-22 Thread Ruben Kerkhof

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 deamontools
> on other Linux distributions. Until now I never did this on Ubuntu.
>
> Is there a comparable way to configure such a watcher on services on Ubuntu
> (i.e. under systemd)?

Systemd handles this for you.
The ceph-mon unit file has:

Restart=on-failure
StartLimitInterval=30min
StartLimitBurst=3

Note that systemd only restarts it 3 times in 30 minutes. If it fails
more often, you'll have to reset the unit.

You can finetune this with drop-ins, see systemd.service(5) for details.

>
> Regards and have a nice weekend.
>
> Steffen

Kind regards,

Ruben Kerkhof
___
ceph-users mailing list
ceph-users@lists.ceph.com
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com

Re: [ceph-users] Ceph rbd jewel

2016-10-22 Thread Ilya Dryomov

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 disable features?

Because even the latest kernel doesn't support all rbd image features,
and for 4.8 and below you need to disable those 4 features.  (4.9-rc1
added support for exclusive-lock, so technically you don't have to
disable it on 4.9, but then exclusive-lock feature not very useful on
its own.)

[1] http://docs.ceph.com/docs/master/rados/operations/crush-map/#tunables

Thanks,

Ilya
___
ceph-users mailing list
ceph-users@lists.ceph.com
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com

Re: [ceph-users] reliable monitor restarts

2016-10-22 Thread Wido den Hollander


> Op 21 oktober 2016 om 21:31 schreef Steffen Weißgerber :
> 
> 
> 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.
> 

That they die is not the thing which should happen! MONs are usually very 
stable. Having them crash is odd and slightly scary.

> To have reliable service restarts I normally use D.J. Bernsteins deamontools
> on other Linux distributions. Until now I never did this on Ubuntu.
> 
> Is there a comparable way to configure such a watcher on services on Ubuntu
> (i.e. under systemd)?

You can run them under upstart which is supported by Ubuntu and Ceph, the 
upstart files are in the ceph packages.

I'd however double-check WHY they crash. Which Ceph version?

Wido

> 
> Regards and have a nice weekend.
> 
> Steffen
> 
> 
> 
> 
> -- 
> Klinik-Service Neubrandenburg GmbH
> Allendestr. 30, 17036 Neubrandenburg
> Amtsgericht Neubrandenburg, HRB 2457
> Geschaeftsfuehrerin: Gudrun Kappich
> ___
> ceph-users mailing list
> ceph-users@lists.ceph.com
> http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
___
ceph-users mailing list
ceph-users@lists.ceph.com
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com

Re: [ceph-users] Question about OSDSuperblock

Re: [ceph-users] Question about OSDSuperblock

Re: [ceph-users] Question about OSDSuperblock

[ceph-users] cache tiering deprecated in RHCS 2.0

[ceph-users] Question about OSDSuperblock

Re: [ceph-users] reliable monitor restarts

Re: [ceph-users] Ceph rbd jewel

Re: [ceph-users] reliable monitor restarts

8 matches

Site Navigation

Mail list logo

Footer information