Messages in this thread | | | Date | Tue, 27 Jun 2006 18:16:32 +1000 | From | Nathan Scott <> | Subject | Re: GFS2 and DLM |
| |
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/
| |