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
