From: Jeff Layton <jlayton@kernel.org>
To: Luis Henriques <lhenriques@suse.com>, Sage Weil <sage@redhat.com>,
Ilya Dryomov <idryomov@gmail.com>, "Yan, Zheng" <zyan@redhat.com>
Cc: ceph-devel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH v2 0/4] ceph: safely use 'copy-from' Op on Octopus OSDs
Date: Thu, 14 Nov 2019 08:15:28 -0500 [thread overview]
Message-ID: <cbda3a69d25b04e10332e7b3898064a93b2d04ae.camel@kernel.org> (raw)
In-Reply-To: <20191114105736.8636-1-lhenriques@suse.com>
On Thu, 2019-11-14 at 10:57 +0000, Luis Henriques wrote:
> Hi!
>
> So, after the feedback I got from v1 [1] I've sent out a pull-request
> for the OSDs [2] which encodes require_osd_release into the OSDMap
> client data. This allows the client to figure out which ceph release
> the OSDs cluster is running and decide whether or not it's safe to use
> the copy-from Op for copy_file_range.
>
> This new patchset I'm sending simply adds enough functionality to the
> kernel client so that it can take advantage of this OSD patch:
>
> 0001 - adds the ability to decode TYPE_MSGR2 addresses. This is a
> required functionality for enabling SERVER_NAUTILUS in the
> client. I hope I got the new format right, as I couldn't figure
> out what the hard-coded values (see comments) really mean.
>
nit: the first 3 patch subject lines should probably be prefixed with
"libceph:"
> 0002 - allows the client to retrieve the new require_osd_release field
> from the OSDMap if available. This patch also adds SERVER_MIMIC,
> SERVER_NAUTILUS and SERVER_OCTOPUS to the supported features,
> which TBH I'm not sure if that's a safe thing to do -- the only
> issue I've seen was that Nautilus requires the ability to decode
> TYPE_MSGR2 address, but I may have missed others.
>
Yes, this needs to be done with care. We have to ensure that the server
side isn't assuming that the client supports something that it doesn't.
I think that means just trawling through the code and verifying whether
this is safe.
> 0003 - debug code to add require_osd_release to the osdmap debugfs file.
>
> 0004 - adds the truncate_{seq,size} fields to the 'copy-from' operation
> if the OSDs are >= Octopus.
>
> Also note that, as suggested by Ilya, I've dropped the patch that would
> change the default mount options to 'copyfrom'.
>
> These patches have been tested with the xfstests generic test suite, and
> with a couple of other (local) tests that exercise the cephfs
> copy_file_range syscall. I didn't saw any issues, but as I said above,
> I'm not really sure if adding the SERVER_* flags to the supported
> features have other side effects.
>
> [1] https://lore.kernel.org/lkml/20191108141555.31176-1-lhenriques@suse.com/
> [2] https://github.com/ceph/ceph/pull/31611
>
I'm just getting caught up on the discussion here, but why was it
decided to do it this way instead of just adding a new OSD
"copy-from-no-truncseq" operation? Once you tried it once and an OSD
didn't support it, you could just give up on using it any longer? That
seems a lot simpler than trying to monkey with feature bits.
--
Jeff Layton <jlayton@kernel.org>
next prev parent reply other threads:[~2019-11-14 13:15 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-14 10:57 [RFC PATCH v2 0/4] ceph: safely use 'copy-from' Op on Octopus OSDs Luis Henriques
2019-11-14 10:57 ` [RFC PATCH v2 1/4] ceph: add support for TYPE_MSGR2 address decode Luis Henriques
2019-11-14 12:18 ` Jeff Layton
2019-11-14 10:57 ` [RFC PATCH v2 2/4] ceph: get the require_osd_release field from the osdmap Luis Henriques
2019-11-14 13:00 ` Jeff Layton
2019-11-14 10:57 ` [RFC PATCH v2 3/4] ceph: add require_osd_release field to osdmap debugfs Luis Henriques
2019-11-14 10:57 ` [RFC PATCH v2 4/4] ceph: add support for sending truncate_{seq,size} in 'copy-from' Op Luis Henriques
2019-11-14 13:15 ` Jeff Layton [this message]
2019-11-14 13:28 ` [RFC PATCH v2 0/4] ceph: safely use 'copy-from' Op on Octopus OSDs Sage Weil
2019-11-14 14:13 ` Ilya Dryomov
2019-11-14 14:17 ` Sage Weil
2019-11-14 15:24 ` Luis Henriques
2019-11-14 15:47 ` Ilya Dryomov
2019-11-14 18:28 ` Gregory Farnum
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=cbda3a69d25b04e10332e7b3898064a93b2d04ae.camel@kernel.org \
--to=jlayton@kernel.org \
--cc=ceph-devel@vger.kernel.org \
--cc=idryomov@gmail.com \
--cc=lhenriques@suse.com \
--cc=linux-kernel@vger.kernel.org \
--cc=sage@redhat.com \
--cc=zyan@redhat.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;
as well as URLs for NNTP newsgroup(s).