From: Loic Dachary <loic@dachary.org>
To: Sage Weil <sage@redhat.com>,
ceph-devel@vger.kernel.org, ceph-users@ceph.com,
ceph-maintainers@ceph.com, ceph-announce@ceph.com
Subject: Re: [Ceph-maintainers] Deprecating ext4 support
Date: Tue, 12 Apr 2016 08:39:38 +0200 [thread overview]
Message-ID: <570C982A.5090600@dachary.org> (raw)
In-Reply-To: <alpine.DEB.2.11.1604111632520.13448@cpach.fuggernut.com>
Hi Sage,
I suspect most people nowadays run tests and develop on ext4. Not supporting ext4 in the future means we'll need to find a convenient way for developers to run tests against the supported file systems.
My 2cts :-)
On 11/04/2016 23:39, Sage Weil wrote:
> Hi,
>
> ext4 has never been recommended, but we did test it. After Jewel is out,
> we would like explicitly recommend *against* ext4 and stop testing it.
>
> Why:
>
> Recently we discovered an issue with the long object name handling that is
> not fixable without rewriting a significant chunk of FileStores filename
> handling. (There is a limit in the amount of xattr data ext4 can store in
> the inode, which causes problems in LFNIndex.)
>
> We *could* invest a ton of time rewriting this to fix, but it only affects
> ext4, which we never recommended, and we plan to deprecate FileStore once
> BlueStore is stable anyway, so it seems like a waste of time that would be
> better spent elsewhere.
>
> Also, by dropping ext4 test coverage in ceph-qa-suite, we can
> significantly improve time/coverage for FileStore on XFS and on BlueStore.
>
> The long file name handling is problematic anytime someone is storing
> rados objects with long names. The primary user that does this is RGW,
> which means any RGW cluster using ext4 should recreate their OSDs to use
> XFS. Other librados users could be affected too, though, like users
> with very long rbd image names (e.g., > 100 characters), or custom
> librados users.
>
> How:
>
> To make this change as visible as possible, the plan is to make ceph-osd
> refuse to start if the backend is unable to support the configured max
> object name (osd_max_object_name_len). The OSD will complain that ext4
> cannot store such an object and refuse to start. A user who is only using
> RBD might decide they don't need long file names to work and can adjust
> the osd_max_object_name_len setting to something small (say, 64) and run
> successfully. They would be taking a risk, though, because we would like
> to stop testing on ext4.
>
> Is this reasonable? If there significant ext4 users that are unwilling to
> recreate their OSDs, now would be the time to speak up.
>
> Thanks!
> sage
>
> _______________________________________________
> Ceph-maintainers mailing list
> Ceph-maintainers@lists.ceph.com
> http://lists.ceph.com/listinfo.cgi/ceph-maintainers-ceph.com
>
--
Loïc Dachary, Artisan Logiciel Libre
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2016-04-12 6:39 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-11 21:39 Deprecating ext4 support Sage Weil
2016-04-11 21:44 ` Sage Weil
2016-04-11 21:57 ` Mark Nelson
[not found] ` <570C1DBC.3040408-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-04-11 22:49 ` Shinobu Kinjo
2016-04-11 23:54 ` [ceph-users] " Robin H. Johnson
2016-04-11 23:09 ` Lionel Bouton
2016-04-12 7:45 ` [ceph-users] " Jan Schermer
2016-04-12 18:00 ` Sage Weil
2016-04-12 19:19 ` Jan Schermer
2016-04-12 19:58 ` Sage Weil
2016-04-12 20:33 ` Jan Schermer
2016-04-12 20:47 ` Sage Weil
[not found] ` <alpine.DEB.2.11.1604121639590.29593-Wo5lQnKln9t9PHm/lf2LFUEOCMrvLtNR@public.gmane.org>
2016-04-12 21:08 ` Nick Fisk
[not found] ` <4f0f087c.9Ro.9Gf.hg.1qX1VyMOaD-ImYt9qTNe79BDgjK7y7TUQ@public.gmane.org>
2016-04-12 21:22 ` wido-fspyXLx8qC4
[not found] ` <362740c3.9Ro.9Gf.hg.1qX1VyMOaE@mailjet.com>
2016-04-12 23:12 ` [ceph-users] " Jan Schermer
2016-04-13 13:13 ` Sage Weil
2016-04-13 13:06 ` Sage Weil
2016-04-14 18:05 ` Jianjian Huo
2016-04-14 18:30 ` Samuel Just
[not found] ` <alpine.DEB.2.11.1604111632520.13448-Wo5lQnKln9t9PHm/lf2LFUEOCMrvLtNR@public.gmane.org>
2016-04-11 21:42 ` Allen Samuels
2016-04-11 21:47 ` [ceph-users] " Jan Schermer
2016-04-11 23:39 ` Christian Balzer
2016-04-12 1:12 ` [ceph-users] " Sage Weil
[not found] ` <alpine.DEB.2.11.1604112046570.29593-Wo5lQnKln9t9PHm/lf2LFUEOCMrvLtNR@public.gmane.org>
2016-04-12 1:32 ` Shinobu Kinjo
2016-04-12 2:05 ` [Ceph-maintainers] " hp cre
2016-04-12 2:43 ` [ceph-users] " Christian Balzer
2016-04-12 13:56 ` Sage Weil
[not found] ` <alpine.DEB.2.11.1604120837120.29593-Wo5lQnKln9t9PHm/lf2LFUEOCMrvLtNR@public.gmane.org>
2016-04-13 3:27 ` Christian Balzer
[not found] ` <20160412083925.5106311d-9yhXNL7Kh0lSCLKNlHTxZM8NsWr+9BEh@public.gmane.org>
2016-04-14 9:43 ` Antw: " Steffen Weißgerber
2016-04-12 7:00 ` Michael Metz-Martini | SpeedPartner GmbH
2016-04-13 2:29 ` [ceph-users] " Christian Balzer
2016-04-13 12:30 ` Sage Weil
2016-04-14 0:57 ` Christian Balzer
2016-04-13 12:51 ` Michael Metz-Martini | SpeedPartner GmbH
2016-04-12 6:39 ` Loic Dachary [this message]
2016-04-13 14:19 ` Francois Lafont
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=570C982A.5090600@dachary.org \
--to=loic@dachary.org \
--cc=ceph-announce@ceph.com \
--cc=ceph-devel@vger.kernel.org \
--cc=ceph-maintainers@ceph.com \
--cc=ceph-users@ceph.com \
--cc=sage@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