[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