On Thu, 3 Nov 2016, Jeff Layton wrote: > 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. I think so. The MDS could always ignore it if it wanted to. Also, the protocol change doesn't need a feature bit since it's only in the message encoding (new field), so there's no need to tie it with the other changes. I commented on the PR how to do that. > 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? I can go either way. Slight preference for kraken. Is it ready? sage
