CEPH filesystem development
 help / color / mirror / Atom feed
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

  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