Re: defaults paths

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



In ceph case, such layout breakage may be necessary in almost all
installations(except testing), comparing to almost all general-purpose
server software which need division like that only in very specific
setups.

On Thu, Apr 5, 2012 at 11:28 AM, Bernard Grymonpon <bernard@xxxxxxxxxxxx> wrote:
> I feel it's up to the sysadmin to mount / symlink the correct storage devices on the correct paths - ceph should not be concerned that some volumes might need to sit together.
>
> Rgds,
> Bernard
>
> On 05 Apr 2012, at 09:12, Andrey Korolyov wrote:
>
>> Right, but probably we need journal separation at the directory level
>> by default, because there is a very small amount of cases when speed
>> of main storage is sufficient for journal or when resulting speed
>> decrease is not significant, so journal by default may go into
>> /var/lib/ceph/osd/journals/$i/journal where osd/journals mounted on
>> the fast disk.
>>
>> On Thu, Apr 5, 2012 at 10:57 AM, Bernard Grymonpon <bernard@xxxxxxxxxxxx> wrote:
>>>
>>> On 05 Apr 2012, at 08:32, Sage Weil wrote:
>>>
>>>> We want to standardize the locations for ceph data directories, configs,
>>>> etc.  We'd also like to allow a single host to run OSDs that participate
>>>> in multiple ceph clusters.  We'd like easy to deal with names (i.e., avoid
>>>> UUIDs if we can).
>>>>
>>>> The metavariables are:
>>>> cluster = ceph (by default)
>>>> type = osd, mon, mds
>>>> id = 1, foo,
>>>> name = $type.$id = osd.0, mds.a, etc.
>>>>
>>>> The $cluster variable will come from the command line (--cluster foo) or,
>>>> in the case of a udev hotplug tool or something, matching the uuid on the
>>>> device with the 'fsid = <uuid>' line in the available config files found
>>>> in /etc/ceph.
>>>>
>>>> The locations could be:
>>>>
>>>> ceph config file:
>>>>  /etc/ceph/$cluster.conf     (default is thus ceph.conf)
>>>>
>>>> keyring:
>>>>  /etc/ceph/$cluster.keyring  (fallback to /etc/ceph/keyring)
>>>>
>>>> osd_data, mon_data:
>>>>  /var/lib/ceph/$cluster.$name
>>>>  /var/lib/ceph/$cluster/$name
>>>>  /var/lib/ceph/data/$cluster.$name
>>>>  /var/lib/ceph/$type-data/$cluster-$id
>>>>
>>>> TV and I talked about this today, and one thing we want is for items of a
>>>> given type to live together in separate directory so that we don't have to
>>>> do any filtering to, say, get all osd data directories.  This suggests the
>>>> last option (/var/lib/ceph/osd-data/ceph-1,
>>>> /var/lib/ceph/mon-data/ceph-foo, etc.), but it's kind of fugly.
>>>>
>>>> Another option would be to make it
>>>>
>>>> /var/lib/ceph/$type-data/$id
>>>>
>>>> (with no $cluster) and make users override the default with something that
>>>> includes $cluster (or $fsid, or whatever) in their $cluster.conf if/when
>>>> they want multicluster nodes that don't interfere.  Then we'd get
>>>> /var/lib/ceph/osd-data/1 for non-crazy people, which is pretty easy.
>>>
>>> As a osd consists of data and the journal, it should stay together, with all info for that one osd in one place:
>>>
>>> I would suggest
>>>
>>> /var/lib/ceph/osd/$id/data
>>> and
>>> /var/lib/ceph/osd/$id/journal
>>>
>>> ($id could be replaced by $uuid or $name, for which I would prefer $uuid)
>>>
>>> Rgds,
>>> Bernard
>>>
>>>>
>>>> Any other suggestions?  Thoughts?
>>>> sage
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
>>>> the body of a message to majordomo@xxxxxxxxxxxxxxx
>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
>>> the body of a message to majordomo@xxxxxxxxxxxxxxx
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> --
>> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
>> the body of a message to majordomo@xxxxxxxxxxxxxxx
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [CEPH Users]     [Ceph Large]     [Information on CEPH]     [Linux BTRFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux