As nautilus is nearing its EOL we are planning to do a next (maybe the
last) point release - nautilus 14.2.22 in the first part of June 2021.
If you have any code changes that are to be included pls raise PRs and
add labels "nautilus -batch1" and "needs-qa", so they can be tested
and merged in time for 14.2.22.
Thx
YuriW
Hi,
With Pacific (16.2.0) out of the door we have the RBD persistent
WriteBack cache for RBD:
https://docs.ceph.com/en/latest/rbd/rbd-persistent-write-back-cache/
Has anybody performed some benchmarks with the RBD cache?
Interested in the QD=1 bs=4k performance mainly.
I don't have any proper hardware available to run benchmarks on yet.
Wido
hi folks,
tl;dr: can we stop building/testing master on bionic for a better GCC?
long story: two months ago, we migrated[0] our CI jobs running "make
check" from ubuntu/bionic to ubuntu/focal so we have access to more
packages offered by focal for testing.
but we are still suffering[1] from the ancient packages offered by bionic:
- buggy tcmalloc. see https://github.com/ceph/ceph/pull/41340
- GCC 7.5.0 shipped along with ubuntu/bionic. i think the support of
std::filesystem is just the tip of the iceberg, as we've migrated to
C++17, there will be more and more demand for a compiler and a
standard library with better C++17 (and C++20 in future) support.
GCC-7 has good support[2] of C++17, but that does not imply that
libstdc++ shipped along with GCC-7 has.
but we have to build and test on bionic[3], for couple reasons:
- some upgrade tests from octopus are performed on bionic. for
instance, see https://github.com/ceph/ceph/tree/master/qa/suites/upgrade/pacific-x/parall…
- cosbench used by perf tests needs bionic: see
https://tracker.ceph.com/issues/49139
- // please note rados/thrash-old-clients/distro$/ubuntu_18.04.yaml is
safe even after we stop building master on bionic, as we've
switched[4] to cephadm for thrash-old-clients
and because of https://tracker.ceph.com/issues/50218, we cannot use
ubuntu-toolchain-r PPA repo for newer GCC.
so, i propose we
- drop building/testing master on bionic.
- drop the upgrade test from pacific on bionic
- drop the cosbench workload from rados/perf test suites
what do you think?
--
[0] https://tracker.ceph.com/issues/49653
[1] https://github.com/ceph/ceph/pull/41433#discussion_r636604231
[2] https://gcc.gnu.org/projects/cxx-status.html
[3] https://github.com/ceph/ceph-build/pull/1794#issuecomment-815435506
[4] https://github.com/ceph/ceph/pull/32377
Next week we've got CDM at EMEA-friendly time: 2 June @ 11am EST
Join us at:
https://bluejeans.com/908675367
There's one rados topic so far, related to unfound/EIO handling
with OSD restarts, and how to test this area better. Thanks te
Jin Hase and Mykola Golub for bringing this up1
Please add further topics here:
https://tracker.ceph.com/projects/ceph/wiki/CDM_02-JUN-2021
Josh
All,
We have two issues:
* https://tracker.ceph.com/issues/45574
* https://tracker.ceph.com/issues/48787
Caused by numpy not supporting Python sub-interpreters. Unfortunately, the
latter issue came up in the most recent Octopus validations. I suspect
it's just
a matter of time, till our users are affected by it.
Note that removing numpy is not easy, as kuberenetes-client depends
(transitively) on numpy.
Thoughts?
- Sebastan
Hi Folks,
The performance meeting will be starting in about 70 minutes. Today the
only topic I have is that we'll discuss whether or not it makes sense to
do another submission for CephFS for the ISC21 IO500 competition.
Please feel free to add your own topic!
Etherpad:
https://pad.ceph.com/p/performance_weekly
Bluejeans:
https://bluejeans.com/908675367
Mark
Hi everyone,
Highlights from this week:
* Ceph User Survey '21: Dashboard analysis
* Some responses looked contradictory (responding not using the
dashboard and then reporting a 5/5 rating)
* Would you recommend dashboard?
- average 6.75
- median 8
* Does the dashboard allow you to perform tasks faster than cli?
- No 52
- Yes 48
* What's most used in the dashboard
- landing page
- iscsi and NFS least used
- RBD > Cephfs consistent Ceph-wise usage
- RGW should rank higher than cephfs 62% vs 54%
* Detractors still use the landing page, cluster logs, mon status, and
grafana dashboards
* Dashboard user Profiles
- Haven't used the dashboard yet
- Older versions of Ceph Dashboard
- Documentation issues?
- Getting started doc refers to the CLI
- Performance concerns?
* monitoring only
- Read-only mode
- Fear of breaking things?
* promoters
* CLI junkies
- Claim: "CLI is faster, easy to remember and scriptable
- Dashboard provides bulk ops and multi-step workflows
- API recorder in OpenAttic:
https://github.com/openattic/openattic/search?q=recorder
- Dashboard maps 1:1 to Ceph CLI
* other mgmt tools
- Using Ceph-ansible, Puppet, Rook
- Other
- Proxmox
- Nagios
* Actions
- Focus efforts on the landing page and cluster logs
- Increase inline docs and contextual helpers
- Add support for bulk ops
- Rest API recorder: generate a script from UI actions
- Publicize dashboard in Ceph blog, tech talks.
* Ceph.io website updates
- The working group's ideal launch date is June 24th
- Content needed for pages
- https://dev.ceph.io/en/
* Market Development Working Group
- The group would like to be more connected with the CLT on the
roadmap for releases.
- they meet once a month.
- they're interested in roadmaps, blog posts,
- Mike: send out pad for gathering high level features/improvements
in Quincy roadmap
* NFS questions on dev@ need answers...
- ganesha and dir_chunk=0 - problematic for RGW exports
* GSOC onboarding / collaboration
- ali to organize
octopus: subinterpreters again
- Planned to be discussed at the next CDM
--
Mike Perez
Adding dev list.
Jeff, is it okay to remove dir_chunk=0 for the cephfs case?
sage
On Tue, May 25, 2021 at 7:43 AM Daniel Gryniewicz <dang(a)redhat.com> wrote:
>
> I think dir_chunk=0 should never be used, even for cephfs. It's not
> intended to be used in general, only for special circumstances (an
> out-of-tree FSAL asked for it, and we use it upstream for debugging
> readdir), and it may go away in a future version of Ganesha.
>
> The rest is probably okay for both of them. However, this raises some
> issues. Some settings, such as dir_chunk=0, Attr_Expiration_Time=0, and
> only_numeric_onwers=true are global to Ganesha. This means that, if
> CephFS and RGW need different global settings, they'd have to run in
> different instances of Ganesha. Is this something we're interested in?
>
> Daniel
>
> On 5/25/21 8:11 AM, Sebastian Wagner wrote:
> > Moving this to upstream, as this is an upstream issue.
> >
> > Hi Mike, hi Sage,
> >
> > Do we need to rethink how we deploy ganesha daemons? Looks like we need
> > different ganesha.conf templates for cephfs and rgw.
> >
> > - Sebastian
> >
> > Am 25.05.21 um 13:59 schrieb Matt Benjamin:
> >> Hi Sebastian,
> >>
> >> 1. yes, I think we should use different templates
> >> 2. MDCACHE { dir_chunk = 0; } is fatal for RGW NFS--it seems suited to
> >> avoid double caching of vnodes in the cephfs driver, but simply cannot
> >> be used with RGW
> >> 3. RGW has some other preferences--for example, some environments
> >> might prefer only_numeric_owners = true; Sage is already working on
> >> extending cephadm to generate exports differently, which should allow
> >> for multiple tenants
> >>
> >> Matt
> >>
> >> On Tue, May 25, 2021 at 7:39 AM Sebastian Wagner <sewagner(a)redhat.com>
> >> wrote:
> >>> Hi Matt,
> >>>
> >>> This is the ganesha.conf template that we use for both cephfs and rgw:
> >>>
> >>> https://github.com/ceph/ceph/blob/master/src/pybind/mgr/cephadm/templates/s…
> >>>
> >>>
> >>> I have the slight impression that we might need to different templates
> >>> for rgw and cephfs?
> >>>
> >>> Best,
> >>> Sebastian
> >
> > ...snip...
> >
>