[Top][All Lists]

[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: Sat, 24 Oct 2009 10:01:35 +0200
User-agent: Mutt/1.5.19 (2009-01-05)


On Tue, Aug 18, 2009 at 05:04:07PM +0200, Thomas Schwinge wrote:
> On Sun, Aug 16, 2009 at 08:57:46PM +0200, olafBuddenhagen@gmx.net
> 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.

But in the mean time it already became obvious that further fixes will
be necessary... It is really getting rather messy.

This was actually intended in part as a generic remark on how to handle
such situations. There is nothing wrong of course with doing a followup
commit to fix some small problem discovered in the original one; but if
it becomes obvious that there are fundamental problems, IMHO a patch
should be reverted, and only commited again once it is in good shape.
Posting several fixup commits over time really messes things up,
especially if there are other commits in between.

(This in turn creates pressure to hold back other commits, which is even
worse. And this is not a theoretical concen -- Sergiu explicitely said
that he is waiting with another, useful commit, until this one is sorted
out! If the broken patch was just reverted, this would not be a

Also, to be able to review the patch, a cumulative version needs to be
posted anyways. While it is possible to extract fixup commits from this,
it is only complicating things.

> > The correct functioning of filesystem syncing is very hard to test;
> > and any errors will be extremely hard to track down later on. Which
> > makes it all the more important that we be able to say with some
> > confidence that the code is really doing the right thing.
> Actually it is not that hard to test once we have a proper testing
> framework.

I don't think so. Note that syncing is asynchronous in nature (pun
almost unintended ;-) ) -- the standard file systems sync automatically
each five seconds, so how do you test this reliably? I don't think it's
possible without special testing modes, or a module testing framework
that allows crafting a controlled situation...


reply via email to

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