On May 26, 2010, at 1:39 PM, Dean Hildebrand wrote: > Try to remember that this isn't some new feature that we are disabling, or a new way of doing things, this is a primary I/O path. We MUST fix this with the B-list code submission, so why go through the hassle of searching through old patches and tags to find it. > To be clear, I am not disabling directIO itself, only directIO's use of pnfs. DirectIO will still be functional, but will use the MDS. Fred > If you want to talk about a *REAL* solution, then we need to figure out who broke O_DIRECT and reject their patches until they fix it. You can't submit patches that break a primary I/O path. But again, since we are focused on A-list items, ifdef'ing the code out for now in the B-list branch seems like a reasonable compromise. > > Dean > > Boaz Harrosh wrote: >> On 05/25/2010 11:14 PM, Dean Hildebrand wrote: >> >>> >>>> I can send some post_submit patches with the code ifdef'ed out if people would be content with that. >>>> >>> Thanks for the background. I would be much happier if you sent patches with the code ifdef'd out, added with the comment in the code regarding which patches you believe introduced the problem. >>> >>> Dean >>> >>>> Fred >>>> >> >> I disagree. Source code is not a version management system. We have git >> for that. The code is never lost it is there for eternity in the git >> tree. We could ask Benny to tag the last branch that had broken directIO >> as LAST_directIO_VERSION for easy random access at future time. >> >> If in the future someone smart wants to forward port the code and fix it >> then the *right* way to do it is by manual octopus merge at the point of >> branch. >> Never, Never uncomment out code that was sitting collecting dust. >> Manual octopus merge I mean using the two diffs from the two sides of the >> branch, and replaying one on the other. For instance if at one patch >> a function was moved, then redo the move of the current function again, not >> leave the old code as it was before. Let the merge point out the points of >> friction. Because you see, with commented code, there is never a merge >> conflict it will always uncomment. >> >> And anyway the Kernel people will never accept code in comments. There >> are out-of-tree gits to do that. So I don't even think it is an option. >> The pnfs branches are patches that should eventually go upstream. Or >> are currently the only option for the testing of upstream code. >> >> Boaz >> -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
