Re: GFS2 and DLM

[Nathan Scott <nathans@sgi.com>]

On Tue, Jun 27, 2006 at 08:33:39AM +0200, Ingo Molnar wrote:
> * Ingo Molnar <mingo@elte.hu> wrote:
> > * Christoph Hellwig <hch@infradead.org> 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.

cheers.

-- 
Nathan
-
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/