[Deepsea-users] Fwd: Detecting disks by their properties rather than by their path

Jan Fajerski jfajerski at suse.com
Wed Dec 21 02:09:05 MST 2016


On Wed, Dec 21, 2016 at 09:46:48AM +0100, Lenz Grimmer wrote:
>Hi all,
>
>stumbled over this idea in the ceph-ansible mailing list and found it
>quite interesting. Is there some merit in being able to select disks
>based on this kind information? How does DeepSea handle this?
>
>Lenz
Yeah I think this is definitely a feature we want. As to how high it is on the 
priority list I don't know.
To a degree though its less of an issue in DeepSea since this (admittedly) long 
list of disks is generated. So while you still need to look at a long and weird 
looking list (the by-id paths are used) if you want to change the proposal, you 
don't need to write it.
>
>
>-------- Forwarded Message --------
>Subject: [Ceph-ansible] Detecting disks by their properties rather than
>by their path
>Date: Thu, 8 Dec 2016 16:51:26 -0500 (EST)
>From: Erwan Velu <evelu at redhat.com>
>To: Ceph-ansible at lists.ceph.com, lgrimmer at suse.de
>
>Hi list,
>
>This is my first contribution to ceph-ansible and wanted to share my
>idea with you and get preliminary feedbacks on it.
>First time I saw ceph-ansible, I was surprised on the way disks are
>defined by naming disks per node with their path like "/dev/sdx"
>
>To my low-level background this is a big issue as :
>- if you have 20-30 disks per node that make a serious list to maintain
>- doesn't garantee what device you select : does /dev/sdx is a usb key,
>an SSD or a rotational drive ?
>- name can change over time : inserting a new disk or rebooting can lead
>to a different name
>
>
>My first approach was about using /dev/disk/by-id/ paths but that tigger
>the following issues :
>- still need a serious list of devices, which is even longer ...
>- name integrate serial number or hexa strings making difficult to
>maintain it, every device is different
>
>I eneded up with the following idea:
>- Why should'nt we choose the disks by their features and let a module
>find the associated path.
>
>The syntax looks like :
>"{'samsung_journal_disks': {'model': 'SAMSUNG MZ7LN512', 'rotational':
>'0', 'count': 2, 'ceph_type': 'journal' }}"
>
>With this syntax, you can select disk by the model, vendor, size, SSD or
>not.
>Then you can specify to get more of that type by specifing the count'
>number : having 10 disks of the same type doesn't make the definition longer
>It is then possible to define what disks are "journals" or "data" by
>defining the ceph_type attribute.
>
>If that definition match the actual system, the module returns the
>associated /dev/disk/by-id/ path like :
>samsung_journal_disks_000 :
>/dev/disk/by-id/scsi-36848f690e68a50001e428e511e4a6c20
>samsung_journal_disks_000 :
>/dev/disk/by-id/scsi-36848f690e68a50001e428e521e55c62b
>
>The real benefit of that is the disks path become the result of a search
>and not a starting point. The disk path have very few value then.
>
>Ceph-ansible will be able to select what disks should be used for what :
>this part is under work.
>
>I wrote a documentation about it, you can have an overview here :
>https://gist.github.com/ErwanAliasr1/b19c62fac061f4f924f587b1973cf0ea
>
>All this work can be found in https://github.com/ceph/ceph-ansible/pull/1128
>
>I didn't detailled everything in this first mail to avoid being too verbose.
>
>I'd love to get your feedbacks on that idea :
>- does it solve issues you already had ?
>- could it be useful for you ?
>
>Cheers,
>Erwan
>_______________________________________________
>Ceph-ansible mailing list
>Ceph-ansible at lists.ceph.com
>http://lists.ceph.com/listinfo.cgi/ceph-ansible-ceph.com
>
>




>_______________________________________________
>Deepsea-users mailing list
>Deepsea-users at lists.suse.com
>http://lists.suse.com/mailman/listinfo/deepsea-users


-- 
Jan Fajerski
Engineer Enterprise Storage
SUSE Linux GmbH
jfajerski at suse.com


More information about the Deepsea-users mailing list