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@xxxxxxxxxxx> wrote:
You can report it here, with more information on what load you were running,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?
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@xxxxxxxxxxx
> http://oss.sgi.com/mailman/listinfo/xfs
_______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
