From: Danny Al-Gaaf <danny@bisect.de>
To: Sage Weil <sage@inktank.com>
Cc: Tommi Virtanen <tv@inktank.com>, ceph-devel@vger.kernel.org
Subject: Re: [PATCH] make mkcephfs and init-ceph osd filesystem handling more flexible
Date: Fri, 02 Nov 2012 10:58:20 +0100 [thread overview]
Message-ID: <5093993C.6000902@bisect.de> (raw)
In-Reply-To: <alpine.DEB.2.00.1208161635290.26904@cobra.newdream.net>
Hi Sage,
sorry for the late reply, was absent some weeks and busy with other issues.
Am 17.08.2012 01:40, schrieb Sage Weil:
> On Thu, 16 Aug 2012, Tommi Virtanen wrote:
>> On Thu, Aug 16, 2012 at 3:32 PM, Sage Weil <sage@inktank.com> wrote:
>>> As for the new options, I suggest:
>>>
>>> * osd fs type
>>> * osd fs devs (will work for mkcephfs, not for new stuff)
>>> * osd fs path
>>> * osd fs options
>>
>> What does osd_fs_path mean, and how is it different from the osd_data dir?
>
> The idea was that you might wand the fs mounted somewhere other that
> osd_data. I'm not sure it's useful; we may as well drop that...
>
>> I'm expecting to need both mkfs-time options (btrfs metadata block
>> size etc) and mount-time options (noatime etc).
>>
>> It would be nice if there was a way to set the options for all
>> fstypes, and then just toggle which one is used (by default). That
>> avoids bugs like trying to mkfs/mount btrfs with xfs-specific options,
>> and vice versa.
>>
>> I'm not sure how well our config system will handle dynamic variable
>> names -- ceph-authtool was fine with me just putting data in
>> osd_crush_location, and we don't need to access these variables from
>> C++, so it should be fine. If you really wanted to, you could probably
>> cram the them into a single variable, with ad hoc structured data in
>> the string value, but that's ugly.. Or just hardcode the list of
>> possible filesystems, and then it's not dynamic variable names
>> anymore.
>
> Yeah, ceph-conf will happily take anything. The C++ code has to do
> slightly more work to get arbitrary config fields, but that's not an
> issue.
>
>> So I'm dreaming of something like:
>>
>> [osd]
>> # what mount options will be passed when an osd data disk is using
>> # one of these filesystems; these are passed to mount -o
>> osd mount options btrfs = herp,foo=bar
>> osd mount options xfs = noatime,derp
>>
>> # what mkfs options are used when creating new osd data disk
>> # filesystems
>> osd mkfs options btrfs = --hur
>> osd mkfs options xfs = --dur
>>
>> # what fstype to use by default when mkfs'ing; mounting will detect
>> # what's there (with blkid) and work with anything
>> osd mkfs type = btrfs
I will prepare a patch with these for the current mkcephfs and init-ceph
incl. aliases for the old keys and cmdline options where possible.
>> # this may go away with "mkcephfs 2.0", and it will have to get more
>> # complex if we provide something for journals too, etc, because you
>> # may want to pair specific data disks to specific journals (DH has
>> # this need).. haven't had time to think it through, which is why i'm
>> # leaning toward "and here's a hook where you run something on the
>> # host that calls ceph-disk-prepare etc on all the disks you want",
>> # and using uuids to match journals to data disks -- this work has
>> # not yet started)
>> osd fs devs = /dev/sdb /dev/sdc
>
> This all looks good to me. What do you think, Danny?
This part (osd fs devs) is for a new mkcepfs.2.0 if I understand you
correctly. Sounds okay for me atm. (Tommi: Are there any new information
on this? Did you already start to work on this?)
Danny
next prev parent reply other threads:[~2012-11-02 10:16 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-09 15:42 [PATCH] make mkcephfs and init-ceph osd filesystem handling more flexible Danny Kukawka
2012-08-09 16:26 ` Tommi Virtanen
2012-08-09 16:46 ` Jim Schutt
2012-08-09 16:53 ` Tommi Virtanen
2012-08-09 17:03 ` Danny Kukawka
2012-08-09 17:12 ` Tommi Virtanen
2012-08-10 1:53 ` Sage Weil
2012-08-10 2:01 ` Xiaopong Tran
2012-08-09 16:49 ` Danny Kukawka
2012-08-09 16:54 ` Tommi Virtanen
2012-08-10 15:54 ` Sage Weil
2012-08-10 16:03 ` Danny Kukawka
2012-08-10 16:12 ` Sage Weil
2012-08-10 16:57 ` Mandell Degerness
2012-08-16 22:32 ` Sage Weil
2012-08-16 22:52 ` Tommi Virtanen
2012-08-16 22:55 ` Tommi Virtanen
2012-08-16 23:40 ` Sage Weil
2012-11-02 9:58 ` Danny Al-Gaaf [this message]
2012-11-02 11:13 ` Sage Weil
2012-11-15 0:12 ` Sage Weil
2012-11-15 10:32 ` Danny Al-Gaaf
2012-11-15 15:05 ` Sage Weil
2012-11-21 0:23 ` Sage Weil
2012-11-21 10:20 ` Danny Al-Gaaf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5093993C.6000902@bisect.de \
--to=danny@bisect.de \
--cc=ceph-devel@vger.kernel.org \
--cc=sage@inktank.com \
--cc=tv@inktank.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox