Re: GFS2 and DLM

[Ingo Molnar]

* Ingo Molnar <mingo@xxxxxxx> wrote:

> * Christoph Hellwig <hch@xxxxxxxxxxxxx> 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:

 fs/xfs/xfs_log.c:

 STATIC void
 xlog_state_ticket_alloc(xlog_t *log)
 {
 [...]
         /*
          * The kmem_zalloc may sleep, so we shouldn't be holding the
          * global lock.  XXXmiken: may want to use zone allocator.
          */
         buf = (xfs_caddr_t) kmem_zalloc(NBPP, KM_SLEEP);

         s = LOG_LOCK(log);

         /* Attach 1st ticket to Q, so we can keep track of allocated memory */
         t_list = (xlog_ticket_t *)buf;
         t_list->t_next = log->l_unmount_free;
 [...]

where kmem_zalloc() may fail!!!

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.

Just in case anyone says 'preallocate': that's _hard_ to do in a 
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.

Btw., i have just taken a 5 minute tour into XFS, and i found at least 5 
other problems with the XFS code that are similar in nature to the ones 
you pointed out. (mostly useless wrappers around Linux functionality) 
Isnt this whole episode highly hypocritic to begin with?

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