lkml.org 
[lkml]   [2006]   [Jun]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: GFS2 and DLM

* Andrew Morton <akpm@osdl.org> wrote:

> > it is relevant to a certain degree, because it creates a (IMO) false
> > impression of merging showstoppers. After months of being in -mm,
> > and after addressing all issues that were raised (and there was a
> > fair amount of review activity December last year iirc), one week
> > prior the close of the merge window a 'huge' list of issues are
> > raised. (after belovingly calling the GFS2 code a "huge mess", to
> > create a positive and productive tone for the review discussion i
> > guess.)
>
> It's a general problem - our reviewing resources do not have the
> capacity to cover our coding resources. This is especially the case
> on filesystems. We'd have merged (a very different) reiser4 a year
> ago if things were in balance.

and just this very minute what gets merged upstream? A chunk of OCFS2
code that has this comment in it:

* NOTE: the allocation error cases here are scary
* we really cannot afford to fail an alloc in recovery
* do we spin? returning an error only delays the problem really

plus this code:

/* sleep for a bit in hopes that we can avoid
* another ENOMEM */
msleep(100);
goto retry;

and this:

/* TODO Look into replacing msleep with cond_resched() */
msleep(100);
goto retry;

and this:

/* yield a bit to allow any final network messages
* to get handled on remaining nodes */
msleep(100);

and this:

if (status < 0) {
mlog(ML_ERROR, "%s: failed to alloc recovery area, "
"retrying\n", dlm->name);
msleep(1000);
}

and this:

} else {
/* -ENOMEM on the other node */
mlog(0, "%s: node %u returned "
"%d during recovery, retrying "
"after a short wait\n",
dlm->name, ndata->node_num,
status);
msleep(100);
}

and that's just from a 60 seconds scan.

and we are not merging GFS2 that does an honest __GFP_NOFAIL for a hard
to solve problem? (Btw., __GFP_NOFAIL is actually more robust due to the
congestion sleep it does, it is more reviewable and more fixable thing
than an open-coded msleep() or cond_resched().)

"Hypocrisy", "double standard", "pot calling the kettle black" is pretty
much the nicest words that come to mind :-(

[and again, i'm not blaming XFS or OCFS2 here.]

Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-06-27 11:11    [W:0.332 / U:0.084 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site