bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Implement the sync libnetfs stubs.


From: olafBuddenhagen
Subject: Re: [PATCH] Implement the sync libnetfs stubs.
Date: Sun, 16 Aug 2009 20:41:27 +0200
User-agent: Mutt/1.5.19 (2009-01-05)

Hi,

On Mon, Aug 03, 2009 at 09:19:17PM +0300, Sergiu Ivanov wrote:
> On Sat, Jul 18, 2009 at 08:08:20AM +0200, olafBuddenhagen@gmx.net wrote:
> > On Sun, Jul 12, 2009 at 10:50:07PM +0300, Sergiu Ivanov wrote:
> > > On Sat, Jul 11, 2009 at 03:56:02AM +0200, olafBuddenhagen@gmx.net wrote:
> > > > On Wed, Jul 08, 2009 at 10:30:41PM +0300, Sergiu Ivanov wrote:

> > So there is no other way to associate the two lists? This is ugly
> > indeed. In this case, I think it would be better not to use the iterator
> > at all -- what you did here looks really hackish, and it breaks the
> > iterator paradigm anyways...
> 
> Yeah, true, it breaks the paradigm.  However, I actually borrowed this
> piece of code from node_init_root (node.c), so this is the style used
> in unionfs.  Should I forget about consistency in this case, what do
> you think?

If the code is indeed copied, it's probably better to keep it as is.

> > > > > @@ -290,7 +322,10 @@ netfs_attempt_sync (struct iouser *cred, struct 
> > > > > node *np,
> > > > >  error_t
> > > > >  netfs_attempt_syncfs (struct iouser *cred, int wait)
> > > > >  {
> > > > > -  return 0;
> > > > > +  /* The complete list of ports to the merged filesystems is
> > > > > +     maintained in the root node of unionfs, so if we sync it, we 
> > > > > sync
> > > > > +     every single merged directory.  */
> > > > > +  return netfs_attempt_sync (cred, netfs_root_node, wait);
> > > > 
> > > > I'm don't think this is really the right approach. Why not forward the
> > > > syncfs to all unioned filesystems?
> > > 
> > > Fredrik told me in another mail that it might happen that I won't have
> > > the right to get the control port of the filesystem I'm working with.
> > 
> > We don't need the control port -- file_syncfs(), as the name says, is a
> > file RPC, not an fsys RPC.
> 
> Ah, so you mean forwarding syncfs to all unioned *directories*?
> Sorry, I thought your were talking about doing fsys_syncfs on all
> unioned *filesystems* :-)

Yes, I meant forwarding the syncfs to all the root nodes of the unioned
file systems.

> In this case, I'd tell you that the current implementation does
> exactly what you are talking about: sends file_sync to all writeable
> directories maintained by unionfs :-)

No, no, no! I said file_syncfs(), not file_sync()!

I don't know enough about this stuff, to say with confidence how these
RPCs differ exactly; but I have absolutely no doubt that there is a good
*reason* for the existence of both. I simply don't believe that
implementing one in terms of the other has the right effect.

-antrik-




reply via email to

[Prev in Thread] Current Thread [Next in Thread]