AUFS triggers Kernel BUG() in nfs_do_writepage (write.c:276)
Subsystems (2)
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): 3217.1283139187@jrobl
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): 7041.1283154060@jrobl
Am 30.08.2010 09:41, schrieb [email protected]:
Quoted 11 lines
David Mudrich:
Quoted 2 lines
I attached the information you asked for. It seems difficult to have a realistic test without AUFS, as it is mounted at the root directory.
Thanx.
It is difficult for me too.
Although I am not confident, these commits (from latest mainline) are worth to try. If you have no way other than this, you should try.J. R. Okajima
Hello,
I applied the patch, same issue.
I attached dmesg | tail -n 50.
I just tried nfsvers=2 and it works.
The problem must be connected with nfs3 writeback.
A copy of this mail goes to the linux-nfs list, maybe they can help to further narrow this.
Regards
David Mudrich
udev: starting version 151
eth1: no IPv6 routers present
eth0: no IPv6 routers present
------------[ cut here ]------------ kernel BUG at fs/nfs/write.c:276! invalid opcode: 0000 [#1] SMP last sysfs file: /sys/devices/virtio-pci/virtio2/net/eth0/ifindex CPU 0 Modules linked in:
Pid: 2069, comm: ns-slapd Not tainted 2.6.35.3.x86_64.aufs #5 /Bochs
RIP: 0010:[<ffffffff811b66a1>] [<ffffffff811b66a1>] nfs_do_writepage+0x201/0x210 RSP: 0018:ffff88007ca8bbf8 EFLAGS: 00010202 RAX: 0000000000000001 RBX: ffff8800378cb900 RCX: 0000000000000001 RDX: 0000000000002cd0 RSI: 000000000000000b RDI: ffff8800378f0400 RBP: ffffea000131f728 R08: ffff88007ca8bb08 R09: 0000000000000000 R10: 00000000ffffffff R11: ffff88005890be88 R12: 0000000000000000 R13: 0000000000000000 R14: ffff88007ca8bd98 R15: ffff88007ca8be18 FS: 00007fe0ec51a7c0(0000) GS:ffff880001800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 00007fe0ed1be008 CR3: 000000007c724000 CR4: 00000000000006b0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process ns-slapd (pid: 2069, threadinfo ffff88007ca8a000, task ffff88007c44c000) Stack: ffffffff811df7c0 ffffffff810a7dda ffff88007c44c000 0000000000000000 <0> 0000000000000002 ffffea000131f728 ffff88005889d8a0 000000000000020a <0> ffffea000131f728 0000000000000000 ffff88007ca8bcd0 ffffffff811b6cd6 Call Trace: [<ffffffff811df7c0>] ? au_do_flush_nondir+0x0/0x30 [<ffffffff810a7dda>] ? find_get_pages_tag+0x3a/0x110 [<ffffffff811b6cd6>] ? nfs_writepages_callback+0x16/0x40 [<ffffffff811df7c0>] ? au_do_flush_nondir+0x0/0x30 [<ffffffff810af4c1>] ? write_cache_pages+0x1a1/0x370 [<ffffffff811b6cc0>] ? nfs_writepages_callback+0x0/0x40 [<ffffffff811df7c0>] ? au_do_flush_nondir+0x0/0x30 [<ffffffff811b6c36>] ? nfs_writepages+0xa6/0x130 [<ffffffff811b7fb0>] ? nfs_flush_one+0x0/0xe0 [<ffffffff810a9159>] ? __filemap_fdatawrite_range+0x49/0x50 [<ffffffff810a91ba>] ? filemap_write_and_wait_range+0x5a/0x80 [<ffffffff811061db>] ? vfs_fsync_range+0x5b/0xa0 [<ffffffff811d4ce5>] ? vfsub_flush+0x25/0x60 [<ffffffff811ddfb0>] ? au_do_flush+0xb0/0x160 [<ffffffff810e0075>] ? filp_close+0x35/0x90 [<ffffffff810e017f>] ? sys_close+0xaf/0x120 [<ffffffff81029602>] ? system_call_fastpath+0x16/0x1b Code: ff ff 48 63 d8 e9 0c ff ff ff 0f 0b eb fe 0f 1f 40 00 48 83 c7 48 31 f6 e8 fd 4b f0 ff e9 69 ff ff ff 48 8b 45 10 e9 36 ff ff ff <0f> 0b eb fe 66 66 2e 0f 1f 84 00 00 00 00 00 48 83 ec 68 ba 14 RIP [<ffffffff811b66a1>] nfs_do_writepage+0x201/0x210 RSP <ffff88007ca8bbf8> ---[ end trace bbaf776e773b4f25 ]---
Quoted 12 lines · David Mudrich
Am 30.08.2010 09:41, schrieb [email protected]:
Quoted 11 lines
David Mudrich:
Quoted 2 lines
I attached the information you asked for. It seems difficult to have a realistic test without AUFS, as it is mounted at the root directory.
Thanx.
It is difficult for me too.
Although I am not confident, these commits (from latest mainline) are worth to try. If you have no way other than this, you should try.J. R. Okajima
Quoted 7 lines
Hello,
I applied the patch, same issue.
I attached dmesg | tail -n 50.I just tried nfsvers=2 and it works.
The problem must be connected with nfs3 writeback.
Two-phase NFSv3 writes are not like most other file system implementations, so it's not surprising that AUFS might be tripped up.
A possible workaround: If you specify the "sync" mount option when the client mounts the NFS server, it will disable UNSTABLE NFSv3 writes.
Quoted 7 lines
A copy of this mail goes to the linux-nfs list, maybe they can help to further narrow this.
Regards
David Mudrich
<log.txt>
Signature · 1 line
chuck[dot]lever[at]oracle[dot]com
Am 30.08.2010 19:28, schrieb Chuck Lever:
Quoted 16 lines · David Mudrich
Quoted 15 lines
Am 30.08.2010 09:41, schrieb [email protected]:
Quoted 11 lines
David Mudrich:
Quoted 2 lines
I attached the information you asked for. It seems difficult to have a realistic test without AUFS, as it is mounted at the root directory.
Thanx.
It is difficult for me too.
Although I am not confident, these commits (from latest mainline) are worth to try. If you have no way other than this, you should try.J. R. Okajima
Hello,
Quoted 8 lines
Quoted 5 lines
I applied the patch, same issue.
I attached dmesg | tail -n 50.I just tried nfsvers=2 and it works.
The problem must be connected with nfs3 writeback.Two-phase NFSv3 writes are not like most other file system implementations, so it's not surprising that AUFS might be tripped up.
A possible workaround: If you specify the "sync" mount option when the client mounts the NFS server, it will disable UNSTABLE NFSv3 writes.
mount -o sync was enabled all the time.
Quoted 7 lines
Quoted 7 lines
A copy of this mail goes to the linux-nfs list, maybe they can help to further narrow this.
Regards
David Mudrich
<log.txt>