bug-hurd
[Top][All Lists]
Advanced

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

[PATCH] Implement the sync libnetfs stubs.


From: Sergiu Ivanov
Subject: [PATCH] Implement the sync libnetfs stubs.
Date: Tue, 17 Nov 2009 12:30:56 +0200
User-agent: Mutt/1.5.20 (2009-06-14)

* netfs.c (netfs_attempt_sync): Sync every directory associated
with the supplied node.
(netfs_attempt_syncfs): Send file_syncfs to every directory
maintained by unionfs.
---

Hello,

On Fri, Nov 06, 2009 at 09:58:31AM +0100, olafBuddenhagen@gmx.net wrote:
> On Wed, Nov 04, 2009 at 06:56:41PM +0200, Sergiu Ivanov wrote:
> > On Mon, Oct 26, 2009 at 01:03:29AM +0100, olafBuddenhagen@gmx.net
> > wrote:
> 
> > > I think the initialization of "i" should be as close to the loop as
> > > possible -- after all, it's a loop counter...
> > 
> > I moved it closer to the loop itself, but I didn't move it further
> > than locking the mutex, because locking the mutex is also a part of
> > initialization, and I am somehow inclined to keep variable definitions
> > before operations (but this is subjective).
> 
> Yes, I also think definitions should go before statements; I said so
> myself in some earlier mail...
> 
> However, I didn't mean moving the *definition*, but the *initialization*
> -- quite a different thing :-)

Ah, sorry :-( I didn't pay attention to this.  I've left the
definition of the variable where it was in the latest version of the
patch and put the initialization immediately before the loop.
 
> Not sure though whether it makes sense to move it inside the mutex
> lock... I see advantages to both variants. However, it might make sense
> to move the comment for the loop above the initialization and/or the
> mutex. (Again, I'm not sure... Just an idea.)

It somehow feels more natural to me to initialize the variable
immediately before the loop.  It is probably due to the standard for
(*i = 0*; ...) :-)
 
> > > Not sure whether I asked this before: is there actually any reason
> > > not to attempt syncing filesystems without FLAG_ULFS_WRITABLE as
> > > well?...
> > > 
> > > (I don't know how file_sync() or file_syncfs() bahave on filesystems
> > > or nodes that really are not writable -- but IIRC that's not what
> > > FLAG_ULFS_WRITABLE conveys anyways?...)
> > 
> > A quick search didn't reveal any indications about whether these RPCs
> > should fail on a really read-only filesystem, so, technically, syncing
> > such filesystems should not be a problem.
[...]
> > That's why I think I agree with you and I made unionfs sync every
> > unioned directory.
> 
> Well, did you actually test how it behaves with really readonly
> filesystems? (Most notably that it doesn't return an error status?)

As an example of a readonly filesystem I took xmlfs and took a glance
at it's implementation of netfs sync stubs.  And then it flashed in my
mind that all implementations of sync stubs that I've seen and which
did nothing returned 0.  I can't remember this being specified as a
convention somewhere, though.

Regards,
scolobb

---
 netfs.c |   80 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--
 1 files changed, 77 insertions(+), 3 deletions(-)

diff --git a/netfs.c b/netfs.c
index 89d1bf6..3988cc7 100644
--- a/netfs.c
+++ b/netfs.c
@@ -1,5 +1,6 @@
 /* Hurd unionfs
-   Copyright (C) 2001, 2002, 2003, 2005 Free Software Foundation, Inc.
+   Copyright (C) 2001, 2002, 2003, 2005, 2009 Free Software Foundation, Inc.
+
    Written by Moritz Schulte <moritz@duesseldorf.ccc.de>.
 
    This program is free software; you can redistribute it and/or
@@ -282,7 +283,45 @@ error_t
 netfs_attempt_sync (struct iouser *cred, struct node *np,
                    int wait)
 {
-  return EOPNOTSUPP;
+  /* The error we are going to report back (last failure wins).  */
+  error_t final_err = 0;
+
+  /* The information about the currently analyzed filesystem.  */
+  ulfs_t * ulfs;
+
+  /* The index of the currently analyzed filesystem.  */
+  int i;
+
+  mutex_lock (&ulfs_lock);
+
+  /* Sync every directory associated with `np`.
+
+     TODO: Rewrite this after having modified ulfs.c and node.c to
+     store the paths and ports to the underlying directories in one
+     place, because now iterating over both lists looks ugly.  */
+  i = 0;
+  node_ulfs_iterate_unlocked (np)
+  {
+    error_t err;
+
+    /* Get the information about the current filesystem.  */
+    err = ulfs_get_num (i, &ulfs);
+    assert (!err);
+
+    /* Since `np` may not necessarily be present in every underlying
+       directory, having a null port is perfectly valid.  */
+    if (node_ulfs->port != MACH_PORT_NULL)
+      {
+       err = file_sync (node_ulfs->port, wait, 0);
+       if (err)
+         final_err = err;
+      }
+
+    ++i;
+  }
+
+  mutex_unlock (&ulfs_lock);
+  return final_err;
 }
 
 /* This should sync the entire remote filesystem.  If WAIT is set,
@@ -290,7 +329,42 @@ netfs_attempt_sync (struct iouser *cred, struct node *np,
 error_t
 netfs_attempt_syncfs (struct iouser *cred, int wait)
 {
-  return 0;
+  /* The error we are going to report back (last failure wins).  */
+  error_t final_err = 0;
+
+  /* The index of the currently analyzed filesystem.  */
+  int i = 0;
+
+  /* The information about the currently analyzed filesystem.  */
+  ulfs_t * ulfs;
+
+  mutex_lock (&ulfs_lock);
+
+  /* Sync every unioned directory maintained by unionfs.
+
+     TODO: Rewrite this after having modified ulfs.c and node.c to
+     store the paths and ports to the underlying directories in one
+     place, because now iterating over both lists looks ugly.  */
+  node_ulfs_iterate_unlocked (netfs_root_node)
+  {
+    error_t err;
+
+    /* Get the information about the current filesystem.  */
+    err = ulfs_get_num (i, &ulfs);
+    assert (err == 0);
+
+    /* Note that, unlike the situation in netfs_attempt_sync, having a
+       null port on the unionfs root node is abnormal.  */
+    assert (node_ulfs->port != MACH_PORT_NULL);
+    err = file_syncfs (node_ulfs->port, wait, 0);
+    if (err)
+      final_err = err;
+
+    ++i;
+  }
+
+  mutex_unlock (&ulfs_lock);
+  return final_err;
 }
 
 /* lookup */
-- 
1.6.5.2





reply via email to

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