Re: AUFS triggers Kernel BUG() in nfs_do_writepage (write.c:276)

Re: AUFS triggers Kernel BUG() in nfs_do_writepage (write.c:276)

[David Mudrich]

[-- Attachment #1: Type: text/plain, Size: 704 bytes --]

  Am 30.08.2010 09:41, schrieb sfjro@users.sourceforge.net:
> David Mudrich:
>> 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

[-- Attachment #2: log.txt --]
[-- Type: text/plain, Size: 2651 bytes --]

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 ]---

Re: AUFS triggers Kernel BUG() in nfs_do_writepage (write.c:276)

[Chuck Lever]

On Aug 30, 2010, at 9:57 AM, David Mudrich wrote:

> Am 30.08.2010 09:41, schrieb sfjro@users.sourceforge.net:
>> David Mudrich:
>>> 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.

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.

> A copy of this mail goes to the linux-nfs list, maybe they can help to further narrow this.
> 
> 
> Regards
> 
> David Mudrich
> <log.txt>

-- 
chuck[dot]lever[at]oracle[dot]com

Re: AUFS triggers Kernel BUG() in nfs_do_writepage (write.c:276)

[David Mudrich]

  Am 30.08.2010 19:28, schrieb Chuck Lever:
> On Aug 30, 2010, at 9:57 AM, David Mudrich wrote:
>
>> Am 30.08.2010 09:41, schrieb sfjro@users.sourceforge.net:
>>> David Mudrich:
>>>> 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.
> 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.
>> A copy of this mail goes to the linux-nfs list, maybe they can help to further narrow this.
>>
>>
>> Regards
>>
>> David Mudrich
>> <log.txt>