On 26.08.2014 17:19, Ivan Zhakov wrote:
> I propose to design and implement all major performance related
> changes of the current FSFS format in the experimental FSX format.
You do realise, I hope, that it's quite likely that FSX will end up
having very little in common with FSFS. It might not even be a
monolithic filesystem; remember we talked about splitting the current FS
into two modules, metadata and content; if we do that in FSX, we'll have
FSX-meta and FSX-content and neither will be close to FSFS.
Your proposal therefore boils down to requiring someone to maintain
/two/ experimental codebases, FSFSv7 and FSX. And I didn't see you
volunteer for either of those tasks ...
(FWIW, maintaining the remove-log-addressing branch doesn't count, and
frankly I have a hard time imagining how that branch could be less buggy
than trunk, given that it's received far less attention and testing.)
> I mean features exactly like revprop caching and log addressing.
>
> The best possible option for such features is to be implemented and
> released as a part of experimental FSX. Then, when we will be really
> sure that everything is fine and it works for the wide number of users,
> we can selectively port (not merge) some of the features into the FSFS.
See above. At some point, merges between FSX and FSFS will become about
as reasonable as merges between BDB and FSFS.
> We have successfully followed this approach in the past (FSFS itself
> and ra_serf) and currently I do not see any reasons to change this
> approach for features I'm talking about.
You must have forgotten the history of ra_serf: almost nobody used it
until we made it the default and only option, and so we only started
getting useful feedback after the 1.8.0 release.
> Moreover, we have discussed
> this on Berlin 2013 hackathon [1]:
> [[[
> stefan2 expressed that while he is confident that FSFSv7 is solid code,
> it's also quite critical and could easily take a year or more to fully
> stabilize. Attendees felt that perhaps it would be best to introduce FSFSv7
> as a new, experimental fs-type. Stefan said he had been thinking
> about the same thing himself, even considering a different name for
> his implementation.
> ]]]
Yup, we did; more than a year ago. A lot has changed since then.
> At this point I'm '-1' to:
> 1) release the improved version of revprop caching to the FSFS format [2]
You did not even review the branch, or if you did, you didn't write
anything to the dev@ list about it. I'll even go as far as to suspect
that you're not aware there's no revprop caching on trunk right now. So
what's your argument for the veto? The intent of the changes on the
branch is to fix an existing serious bug in released code.
> 2) release the log addressing feature in the FSFSv7 format
I've asked you about a dozen times now to point out actual flaws in the
log addressing implementation. The performance regression you found has
been fixed, and other than that, I don't recall you having any other
concrete issue than the fact that there are actual code changes involved.
Furthermore, there are more new features in trunk FSFS than just log
addressing, and that is arguably the most exhaustively tested of those
features. Why do you keep talking only about log addressing and not, for
example, non-blocking packing? That's a performance enhancement, too.
-- Brane
Received on 2014-09-04 10:34:59 CEST