[lkml]   [2006]   [Jun]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: GFS2 and DLM
On Tue, Jun 27, 2006 at 08:33:39AM +0200, Ingo Molnar wrote:
> * Ingo Molnar <> wrote:
> > * Christoph Hellwig <> wrote:
> >
> > > The code uses GFP_NOFAIL for slab allocator calls. It's been
> > > pointed out here numerous times that this can't work. Andrew, what
> > > about adding a check to slab.c to bail out if someone passes it?
> >
> > reiserfs, jbd and NTFS are all using GFP_NOFAIL ...
> >
> > i dont think this is a huge issue that should block merging.
> oh, and XFS has this little gem in its journalling code:

[snip misinterpreted code/flag]

> */
> buf = (xfs_caddr_t) kmem_zalloc(NBPP, KM_SLEEP);
> [...]
> where kmem_zalloc() may fail!!!

Not with the flags it was given.

> So XFS is apprarently hiding the "journalling allocations must not fail"
> problem by ... crashing? Wow! Most of the other journalling filesystems
> loop on the allocator: the honest ones do it via GFP_NOFAIL, others via
> open-coded infinite retry loops.

No, please look more closely before making such claims.

> sophisticated filesystem, which has many dynamic (and delayed) decisions
> that make the prediction of resource overhead difficult. That's the
> fundamental reason why basically all journalling filesystems either loop
> (or the really enterprise quality ones: crash ;) on allocation failure.

> other problems with the XFS code that are similar in nature to the ones
> you pointed out. (mostly useless wrappers around Linux functionality)

You've missed subtleties in those "useless wrappers", which are
preventing the problem you claim is there.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-06-27 10:20    [W:0.082 / U:1.668 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site