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: Fri, 6 Nov 2009 09:58:31 +0100
User-agent: Mutt/1.5.19 (2009-01-05)

Hi,

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 :-)

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.)

> > 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.  At first, I could not see
> *conceptual* reasons for syncing directories not marked with
> FLAG_ULFS_WRITABLE flag, but I can see one now.  Since this
> unionfs-specific flag only influences the work of unionfs, and unionfs
> does not control *regular* files in unioned directories, a user may
> modify files in directories not marked with FLAG_ULFS_WRITABLE.  On
> invocation of file_sync{,fs} on such a directory, these changes should
> be expected to be synced, too.

Well, one could argue that if unionfs doesn't touch it, it's also not
responsible for syncing... But I guess that's not what clients expect;
and as I said earlier, more syncing can never hurt...

> 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?)

-antrik-




reply via email to

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