On Tue, 2016-11-01 at 13:20 +0000, Sage Weil wrote:
> Hey everyone,
>
> I think we're about ready for a kraken feature freeze. The main item we
> were waiting for was the EC overwrites and Sam has a working branch for
> review this week. There are still a few odds and ends that I have on my
> list to get in (like the new CRUSH tunable), but it's a short list.
>
> How does next Monday (11/7) sound for an initial freeze?
>
>
I have a PR up that I'd like to see go in that fixes some really slow
fsync performance in libcephfs:
https://github.com/ceph/ceph/pull/11710
The catch here is that it requires a protocol change in MClientCaps, so
it'd be good to merge that in with the btime/change_attr stuff before
release. At this point though, I just want to understand whether the
general approach is sound. Do we want to allow the client to hint to
the MDS that it should flush its log.
Also, we probably need to think about what to do with the libcephfs API
overhaul:
https://github.com/ceph/ceph/pull/11647
That will rev the libcephfs version to "2", and break the API. I have
the ganesha and samba patches done.
Do we want that in kraken, or should it wait for luminous?
--
Jeff Layton <jlayton@xxxxxxxxxxxxxxx>
--
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
