Hello, On Tue, Aug 18, 2009 at 05:04:07PM +0200, Thomas Schwinge wrote: > On Sun, Aug 16, 2009 at 08:57:46PM +0200, [email protected] wrote: > > > The origianl patch is wrong and needs to be reverted, and a new one > > comitted once all concerns actually have been addressed. > > A follow-up patch has been published (but not yet installed) that makes > netfs_attempt_sync behave as expected, and I think all of us three agree > that this is correct. I think that this follow-up patch should simply be > installed on top of the one that is in the repository. No need for > reverting anything; for example, even though the patch in the repository > is not totally correct, it already is an improvement as compared to the > situation before. > > Then, what indeed needs discussion is netfs_attempt_syncfs. Instead of > continuing to speculate, I began documenting the Hurd's RPCs. Some of > them are documented in the manual, some are in definition or header > files, some can be second-guessed by looking though library sources that > implement them, etc. Look here (and contribute!): > <http://www.bddebian.com/~hurd-web/hurd/interface/>.
This is great! I've wanted something like this for so long a time! :-) > Especially, I added what I found for file_sync, file_syncfs, and > fsys_syncfs. And the thing is that I couldn't find a really clear > example for the syncfs ones, about their exact modus operandi. What > one does find is that for some implementations they indeed foreward > syncfs to all child servers, but I'm missing a rationale why this is > better than syncing the root directory. But, as the forwarding is > the technique that is already being applied, I have no objections > for changing unionfs' netfs_attempt_syncfs in this way -- Sergiu > also already posted a patch to do that. So, then I think all of us > agree, correct? I suggest: (1.) fix for netfs_attempt_sync is to be > installed on top of the current master; (2.) change for > netfs_attempt_syncfs is to be installed on top of that. It's okay for me. (Though my personal preferences are still with reverting the existing commit.) Regards, scolobb
