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
[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-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
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.