What should to do with ASSERT failed

What should to do with ASSERT failed

[Mike Gao]

[-- Attachment #1.1: Type: text/plain, Size: 380 bytes --]

xfs_vm_writepage
{
               /*
* A hole may still be marked uptodate because discard_buffer
 * leaves the flag set.
 */
if (!buffer_mapped(bh) && buffer_uptodate(bh)) {
 ASSERT(!buffer_dirty(bh));
 imap_valid = 0;
 continue;
}
}

I met this case that buffer is marked as dirty which make assert failed.
What does this mean and what I can do with it?

Thanks very much,
Mike

[-- Attachment #1.2: Type: text/html, Size: 1447 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: What should to do with ASSERT failed

[Eric Sandeen]

Mike Gao wrote:
> xfs_vm_writepage
> {
>                /*
> * A hole may still be marked uptodate because discard_buffer
> * leaves the flag set.
> */
> if (!buffer_mapped(bh) && buffer_uptodate(bh)) {
> ASSERT(!buffer_dirty(bh));
> imap_valid = 0;
> continue;
> }
> }
> 
> I met this case that buffer is marked as dirty which make assert failed. 
> What does this mean and what I can do with it?

You can report it here, with more information on what load you were running,
and the full backtrace that the ASSERT generated... thanks!

And it means that we think we are in a hole, but the buffer for
that hole is marked dirty, which we did not expect ...

The change went in with this commit:

3d9b02e3c76531687ab5314e0edf266256f13c2d xfs: fix corruption case for block size < page size

which was attempting to fix a very specific file corruption case.

What kernel are you running on?

What block size are you using?  (xfs_info will tell you)

Thanks,
-Eric

> Thanks very much,
> Mike
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: What should to do with ASSERT failed

[Mike Gao]

[-- Attachment #1.1: Type: text/plain, Size: 2919 bytes --]

Thanks very much for help. The kernel is pretty old, 2.6.19 but the xfs is
pretty new.
the block size is 512 and use mmap for test with write and read compare.
(xfstest 074).

If I ignored this ASSERT(comment out), the test will failed. I guess because
some pages never written to disk.

Assertion failed: !buffer_dirty(bh), file: fs/xfs/linux-2.6/xfs_aops.c,
line: 1399
BUG: failure at fs/xfs/support/debug.c:108/assfail()!
Kernel panic - not syncing: BUG!

EIP: 0073:[<b76f5424>] CPU: 0 Not tainted ESP: 007b:b75a6fa8 EFLAGS:
00000246
    Not tainted
EAX: 00000000 EBX: 00000e97 ECX: 00000013 EDX: 00000e97
ESI: 00000e93 EDI: 00000011 EBP: b75a6fc4 DS: 007b ES: 007b
0a7d7c94:  [<0806bd41>] show_regs+0xc5/0xca
0a7d7cc0:  [<0805a920>] panic_exit+0x25/0x3f
0a7d7cd4:  [<0807b5d5>] atomic_notifier_call_chain+0x1d/0x33
0a7d7cf4:  [<0807048f>] panic+0x4c/0xcf
0a7d7d10:  [<081724cd>] xfs_hex_dump+0x0/0x7
0a7d7d1c:  [<08168e26>] xfs_vm_writepage+0x226/0x656
0a7d7dbc:  [<0809092f>] generic_writepages+0x164/0x27b
0a7d7e4c:  [<0816926c>] xfs_vm_writepages+0x16/0x18
0a7d7e5c:  [<08090a6a>] do_writepages+0x24/0x38
0a7d7e70:  [<080bbe8b>] __writeback_single_inode+0x16d/0x2de
0a7d7ebc:  [<080bc1ba>] sync_sb_inodes+0x1be/0x25c
0a7d7ef4:  [<080bc299>] writeback_inodes+0x41/0x6c
0a7d7f08:  [<080905b5>] background_writeout+0x66/0x93
0a7d7f54:  [<0809106a>] pdflush+0xca/0x154
0a7d7f88:  [<08080a83>] kthread+0xb6/0xe6
0a7d7fb4:  [<080663ee>] run_kernel_thread+0x37/0x41
0a7d7fe0:  [<0805acee>] new_thread_handler+0x64/0x8b
0a7d7ffc:  [<a55a5a5a>] 0xa55a5a5a

On Mon, Aug 30, 2010 at 4:47 PM, Eric Sandeen <sandeen@sandeen.net> wrote:

> Mike Gao wrote:
> > xfs_vm_writepage
> > {
> >                /*
> > * A hole may still be marked uptodate because discard_buffer
> > * leaves the flag set.
> > */
> > if (!buffer_mapped(bh) && buffer_uptodate(bh)) {
> > ASSERT(!buffer_dirty(bh));
> > imap_valid = 0;
> > continue;
> > }
> > }
> >
> > I met this case that buffer is marked as dirty which make assert failed.
> > What does this mean and what I can do with it?
>
> You can report it here, with more information on what load you were
> running,
> and the full backtrace that the ASSERT generated... thanks!
>
> And it means that we think we are in a hole, but the buffer for
> that hole is marked dirty, which we did not expect ...
>
> The change went in with this commit:
>
> 3d9b02e3c76531687ab5314e0edf266256f13c2d xfs: fix corruption case for block
> size < page size
>
> which was attempting to fix a very specific file corruption case.
>
> What kernel are you running on?
>
> What block size are you using?  (xfs_info will tell you)
>
> Thanks,
> -Eric
>
> > Thanks very much,
> > Mike
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > xfs mailing list
> > xfs@oss.sgi.com
> > http://oss.sgi.com/mailman/listinfo/xfs
>
>

[-- Attachment #1.2: Type: text/html, Size: 3982 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: What should to do with ASSERT failed

[Eric Sandeen]

Mike Gao wrote:
> Thanks very much for help. The kernel is pretty old, 2.6.19 but the xfs
> is pretty new.
> the block size is 512 and use mmap for test with write and read compare.
> (xfstest 074).

Ok so just xfstests 074 with a 512-byte block?  I will test that when
I get a chance....

> If I ignored this ASSERT(comment out), the test will failed. I guess
> because some pages never written to disk.

*nod* I'm afraid that makes sense, it's ignoring this because it
thinks it's a hole:

                /*
                 * A hole may still be marked uptodate because discard_buffer
                 * leaves the flag set.
                 */
                if (!buffer_mapped(bh) && buffer_uptodate(bh)) {
                        ASSERT(!buffer_dirty(bh));
                        imap_valid = 0;
                        continue;
                }

It appears that in your case it should not be a hole...

-Eric
 
> Assertion failed: !buffer_dirty(bh), file: fs/xfs/linux-2.6/xfs_aops.c,
> line: 1399
> BUG: failure at fs/xfs/support/debug.c:108/assfail()!
> Kernel panic - not syncing: BUG!
>  
> EIP: 0073:[<b76f5424>] CPU: 0 Not tainted ESP: 007b:b75a6fa8 EFLAGS:
> 00000246
>     Not tainted
> EAX: 00000000 EBX: 00000e97 ECX: 00000013 EDX: 00000e97
> ESI: 00000e93 EDI: 00000011 EBP: b75a6fc4 DS: 007b ES: 007b
> 0a7d7c94:  [<0806bd41>] show_regs+0xc5/0xca
> 0a7d7cc0:  [<0805a920>] panic_exit+0x25/0x3f
> 0a7d7cd4:  [<0807b5d5>] atomic_notifier_call_chain+0x1d/0x33
> 0a7d7cf4:  [<0807048f>] panic+0x4c/0xcf
> 0a7d7d10:  [<081724cd>] xfs_hex_dump+0x0/0x7
> 0a7d7d1c:  [<08168e26>] xfs_vm_writepage+0x226/0x656
> 0a7d7dbc:  [<0809092f>] generic_writepages+0x164/0x27b
> 0a7d7e4c:  [<0816926c>] xfs_vm_writepages+0x16/0x18
> 0a7d7e5c:  [<08090a6a>] do_writepages+0x24/0x38
> 0a7d7e70:  [<080bbe8b>] __writeback_single_inode+0x16d/0x2de
> 0a7d7ebc:  [<080bc1ba>] sync_sb_inodes+0x1be/0x25c
> 0a7d7ef4:  [<080bc299>] writeback_inodes+0x41/0x6c
> 0a7d7f08:  [<080905b5>] background_writeout+0x66/0x93
> 0a7d7f54:  [<0809106a>] pdflush+0xca/0x154
> 0a7d7f88:  [<08080a83>] kthread+0xb6/0xe6
> 0a7d7fb4:  [<080663ee>] run_kernel_thread+0x37/0x41
> 0a7d7fe0:  [<0805acee>] new_thread_handler+0x64/0x8b
> 0a7d7ffc:  [<a55a5a5a>] 0xa55a5a5a

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: What should to do with ASSERT failed

[Eric Sandeen]

Mike Gao wrote:
> Thanks very much for help. The kernel is pretty old, 2.6.19 but the xfs
> is pretty new.
> the block size is 512 and use mmap for test with write and read compare.
> (xfstest 074).
> 
> If I ignored this ASSERT(comment out), the test will failed. I guess
> because some pages never written to disk.
> 

FWIW, in your case, if you are not expecting to do IO like test 194
then maybe you'd be better off w/o this patch if it's causing problems
in more normal IO patterns ...

-Eric

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: What should to do with ASSERT failed

[Dave Chinner]

On Mon, Aug 30, 2010 at 05:56:07PM -0500, Mike Gao wrote:
> Thanks very much for help. The kernel is pretty old, 2.6.19 but the xfs is
> pretty new.
> the block size is 512 and use mmap for test with write and read compare.
> (xfstest 074).

Can you reproduce it on a more recent kernel? The buffer flags are
modified by code outside XFS which could be significantly different in
2.6.19 comapred to 2.6.34/35, so it may not be aproblem with the
XFS code as such....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: What should to do with ASSERT failed

[Mike Gao]

[-- Attachment #1.1: Type: text/plain, Size: 1177 bytes --]

What kind of logic there could be?

I notice that in old version, if page has no buffer in writepage, then xfs
will create a empty buffer and attach to page. This logic there at least
untill 2.6.33. But now xfs need this never happens (assert) when coming to
writepage.  But I guess, when use mmap, there is no buffer attach to page
because it operates on page directly on kernel. xfs should create buffer
before submit bio. There must be sth I don't know. Maybe sbd can help me
out.

Thanks very much,
Mike


On Mon, Aug 30, 2010 at 7:30 PM, Dave Chinner <david@fromorbit.com> wrote:

> On Mon, Aug 30, 2010 at 05:56:07PM -0500, Mike Gao wrote:
> > Thanks very much for help. The kernel is pretty old, 2.6.19 but the xfs
> is
> > pretty new.
> > the block size is 512 and use mmap for test with write and read compare.
> > (xfstest 074).
>
> Can you reproduce it on a more recent kernel? The buffer flags are
> modified by code outside XFS which could be significantly different in
> 2.6.19 comapred to 2.6.34/35, so it may not be aproblem with the
> XFS code as such....
>
> Cheers,
>
> Dave.
> --
> Dave Chinner
> david@fromorbit.com
>

[-- Attachment #1.2: Type: text/html, Size: 1642 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: What should to do with ASSERT failed

[Dave Chinner]

On Tue, Aug 31, 2010 at 05:50:06PM -0500, Mike Gao wrote:
> What kind of logic there could be?
> 
> I notice that in old version, if page has no buffer in writepage, then xfs
> will create a empty buffer and attach to page. This logic there at least
> untill 2.6.33. But now xfs need this never happens (assert) when coming to
> writepage.  But I guess, when use mmap, there is no buffer attach to page
> because it operates on page directly on kernel. xfs should create buffer
> before submit bio. There must be sth I don't know. Maybe sbd can help me
> out.

mmap() pages used to be special because they weren't tagged
correctly when the page was dirtied. Nowdays the ->page_mkwrite
interface captures those and does the correct processing at page
fault time to set up the buffers. Hence we should never see an
unmapped dirty buffer in writeback. ->page-mkwrite was introduced
around 2.6.18 IIRC, but there has been changes to the way it works
since then. Maybe it is not functioning correctly on your kernel?

However, this is just one example of how buffers are handled
differently _outside XFS_ on older kernels. Nobody will be able to
give you a definitive list of what has changed - you'll only find
those by trolling git logs or testing and tripping over them.

As it is, I'm curious why you are backporting to such an old kernel
rather than just using a newer kernel. Using a newer kernel would
save you a lot of time and effort....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs