On Fri, 30 Jun 2017 16:29:43 +0000 David Turner wrote: > I actually don't see either of these as issues with just flat out saying > that Btrfs will not be supported in Luminous. It's a full new release and > it sounds like it is no longer a relevant Filestore backend in Luminous. > People can either plan to migrate their OSDs to Bluestore once they reach > Luminous or just not upgrade to Luminous. Upgrading is optional and not > mandatory. > You tell that to the people in charge when there's a critical bug in a version that's no longer maintained. At the release cycle speed of Ceph this tends to be an option only for those of us who are happy to freeze a cluster at a certain version until it dies of natural causes. That being said, anybody who deployed BTRFS within the last 1-2 years should have seen the writing on the wall, but the ability of reading between the lines is not an excuse for a "proper deprecation" indeed. And at this time that probably should be extended formally to ZFS. Christian > On Fri, Jun 30, 2017 at 11:47 AM Lenz Grimmer <lenz@xxxxxxxxxxx> wrote: > > > Hi Sage, > > > > On 06/30/2017 05:21 AM, Sage Weil wrote: > > > > > The easiest thing is to > > > > > > 1/ Stop testing filestore+btrfs for luminous onward. We've recommended > > > against btrfs for a long time and are moving toward bluestore anyway. > > > > Searching the documentation for "btrfs" does not really give a user any > > clue that the use of Btrfs is discouraged. > > > > Where exactly has this been recommended? > > > > The documentation currently states: > > > > > > http://docs.ceph.com/docs/master/rados/configuration/ceph-conf/?highlight=btrfs#osds > > > > "We recommend using the xfs file system or the btrfs file system when > > running mkfs." > > > > > > http://docs.ceph.com/docs/master/rados/configuration/filesystem-recommendations/?highlight=btrfs#filesystems > > > > "btrfs is still supported and has a comparatively compelling set of > > features, but be mindful of its stability and support status in your > > Linux distribution." > > > > > > http://docs.ceph.com/docs/master/start/os-recommendations/?highlight=btrfs#ceph-dependencies > > > > "If you use the btrfs file system with Ceph, we recommend using a recent > > Linux kernel (3.14 or later)." > > > > As an end user, none of these statements would really sound as > > recommendations *against* using Btrfs to me. > > > > I'm therefore concerned about just disabling the tests related to > > filestore on Btrfs while still including and shipping it. This has > > potential to introduce regressions that won't get caught and fixed. > > > > > 2/ Leave btrfs in the mix for jewel, and manually tolerate and filter out > > > the occasional ENOSPC errors we see. (They make the test runs noisy but > > > are pretty easy to identify.) > > > > > > If we don't stop testing filestore on btrfs now, I'm not sure when we > > > would ever be able to stop, and that's pretty clearly not sustainable. > > > Does that seem reasonable? (Pretty please?) > > > > If you want to get rid of filestore on Btrfs, start a proper deprecation > > process and inform users that support for it it's going to be removed in > > the near future. The documentation must be updated accordingly and it > > must be clearly emphasized in the release notes. > > > > Simply disabling the tests while keeping the code in the distribution is > > setting up users who happen to be using Btrfs for failure. > > > > Just my 0.02€, > > > > Lenz > > > > _______________________________________________ > > ceph-users mailing list > > ceph-users@xxxxxxxxxxxxxx > > http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com > > -- Christian Balzer Network/Systems Engineer chibi@xxxxxxx Rakuten Communications -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
