Red Hat Bugzilla – Bug 428896
GFS2: warning: assertion "al->al_alloced" failed
Last modified: 2009-05-27 23:39:07 EDT
Description of problem: While running a gfs2.ko w/ Bob's 5th performance patch for bz253990 I started seeing the following message on the console of some nodes. GFS2: fsid=morph-cluster:brawl0.0: warning: assertion "al->al_alloced" failed GFS2: fsid=morph-cluster:brawl0.0: function = alloc_page_backing, file = /builddir/build/BUILD/gfs2-kmod-1.68/_kmod_build_PAE/ops_vm.c, line = 94 [<f8da2bd1>] gfs2_assert_warn_i+0x7e/0x114 [gfs2] [<f8d9b64b>] gfs2_sharewrite_nopage+0x24b/0x299 [gfs2] [<f8d9b443>] gfs2_sharewrite_nopage+0x43/0x299 [gfs2] [<c045ef98>] __handle_mm_fault+0x1d0/0xb23 [<c042e0dc>] lock_timer_base+0x15/0x2f [<c04e23c6>] prio_tree_insert+0x1b/0x1f2 [<c04617be>] vma_link+0x9c/0xb8 [<c0608bb6>] do_page_fault+0x2a5/0x5d3 [<c0608911>] do_page_fault+0x0/0x5d3 [<c0405a71>] error_code+0x39/0x40 ======================= It appears this message started appearing on nodes after they started a test which does mmap operations. Version-Release number of selected component (if applicable): kernel-2.6.18-68.el5 kmod-gfs2-1.68-1.3 How reproducible: My guess, easily.
This basically means that gfs2_write_alloc_required thought that we needed to allocate some blocks for this page fault, but when we came to do the allocation, we discovered that we didn't need to allocate any blocks. I can't see why that should be the case at the moment.
No, I tell a lie. I can see exactly why it fails. Bob's latest patch to gfs2_write_alloc_required is wrong. It tests di_blocks (which is wrong because its the number of blocks allocated to the file, not the size of the file). It ought to be testing (di_size + (block size) - 1) >> (block size shift). Also di_blocks covers all the blocks added to the file and not just the data blocks, so its wrong in the normal case too as its not providing any short cut which was the original idea. You can get the result that you bumped into in the case of a file with a hole in it as then di_blocks will be much smaller than the file size.
Created attachment 291844 [details] Potential fix This should fix it. Its not tested yet, but I'm doing that at the moment.
This was a problem with the fifth performance patch for bug #253990. The patch from comment #3 above has been included in the reworked patch6 for bug @253990, so I'm closing this one as NOTABUG.