* BtrFS does not respond after doing 'fstest' on both original and cloned file
@ 2009-12-09 1:53 Jian Lin
2009-12-09 2:19 ` Yan, Zheng
2009-12-09 2:19 ` Zhang Jingwang
0 siblings, 2 replies; 7+ messages in thread
From: Jian Lin @ 2009-12-09 1:53 UTC (permalink / raw)
To: linux-btrfs
Hi,
I am using Linux 2.6.32 on X86_64 with BtrFS compiled in the kernel.
For my experimental application, I want to evaluate reliability of COW
feature of BtrFS.
I chose a small tool called fstest (http://code.google.com/p/fstest/)
and modified it:
[root@node34 fstest-0.1.3]# diff fstest.c fstest-mod.c
315c315
< unlink(p->filename);
---
> //unlink(p->filename);
317c317
< *file=open(p->filename, O_RDWR|O_CREAT|O_EXCL, 0777);
---
> *file=open(p->filename, O_RDWR|O_CREAT/*|O_EXCL*/, 0777);
360c360
< unlink(p.filename);
---
> //unlink(p.filename);
So, fstest-mod will ramdomly write and read blocks in a specific file,
and check whether it is consistent.
Then I made a zero-filled file and a clone of it, ran fstest-mod
respectively on the original and the cloned file:
dd if=/dev/zero of=testbase bs=100 count=$((1024*1024))
cp --reflink testbase testbase-ref
[One Terminal] ./fstest-mod testbase $((100*1024*1024))
[Another Terminal] ./fstest-mod testbase-ref $((100*1024*1024))
When the test files were small (~100M), both fstest-mod programs returned OK.
However, when I used bigger test files (2G), BtrFS did not respond
after a period of time.
It said:
Message from syslogd@ at Wed Dec 9 08:38:42 2009 ...
node34 kernel: ------------[ cut here ]------------
Message from syslogd@ at Wed Dec 9 08:38:42 2009 ...
node34 kernel: invalid opcode: 0000 [#1] SMP
Message from syslogd@ at Wed Dec 9 08:38:42 2009 ...
node34 kernel: last sysfs file:
/sys/devices/system/cpu/cpu3/cache/index1/shared_cpu_map
Message from syslogd@ at Wed Dec 9 08:38:42 2009 ...
node34 kernel: Stack:
Message from syslogd@ at Wed Dec 9 08:38:42 2009 ...
node34 kernel: Call Trace:
Message from syslogd@ at Wed Dec 9 08:38:42 2009 ...
node34 kernel: Code: 24 10 4c 89 f6 e8 5a 16 fc ff 48 8b 7c 24 20 eb
29 48 8d 6b f0 48 8b 74 24 10 48 8b 7c 24 18 48 89 ea e8 00 4b fd ff
85 c0 74 04 <0f> 0b eb fe 48 89 df e8 c2 a9 05 00 48 89 ef e8 d2 93 f5
ff 48
[root@node34 ~]# cat /sys/devices/system/cpu/cpu3/cache/index1/shared_cpu_map
00000000,00000000,00000000,00000000,00000000,00000000,00000000,0000000a
[root@node34 ~]# ps aux | grep fstest
root 7352 0.7 0.0 3792 456 pts/3 D+ 08:24 3:55
./fstest-mod testbase 2147483648
root 8420 0.0 0.0 61192 740 pts/6 S+ 16:44 0:00 grep fstest
When I tried to list files on BtrFS, ls process also hanged:
[root@node34 ~]# ps aux | grep ls
root 8290 0.0 0.0 73936 884 pts/1 D+ 16:34 0:00 ls --color=tty
root 8327 0.0 0.0 73936 884 ? D 16:35 0:00 ls --color=tty
root 8384 0.0 0.0 73936 884 pts/5 D+ 16:42 0:00 ls
--color=tty /root/linjian/mnt_btrfs
root 8422 0.0 0.0 61192 736 pts/6 S+ 16:44 0:00 grep ls
[root@node34 ~]# ps aux | grep btrfs
root 3967 0.0 0.0 0 0 ? S Dec08 0:00
[btrfs-genwork-0]
root 3968 0.0 0.0 0 0 ? S Dec08 0:39
[btrfs-submit-0]
root 3969 0.0 0.0 0 0 ? S Dec08 0:00
[btrfs-delalloc-]
root 3970 0.0 0.0 0 0 ? S Dec08 0:00 [btrfs-fixup-0]
root 3975 0.0 0.0 0 0 ? S Dec08 0:00
[btrfs-enospc-0]
root 3976 0.0 0.0 0 0 ? S Dec08 0:00 [btrfs-cleaner]
root 3977 0.0 0.0 0 0 ? D Dec08 0:04
[btrfs-transacti]
root 4301 0.2 0.0 0 0 ? S Dec08 3:11
[btrfs-endio-wri]
root 4461 0.7 0.0 0 0 ? S Dec08 8:55
[btrfs-worker-1]
root 4495 0.0 0.0 0 0 ? S Dec08 0:20
[btrfs-endio-met]
root 4601 0.0 0.0 0 0 ? S Dec08 0:34 [btrfs-endio-1]
root 4623 0.0 0.0 0 0 ? S Dec08 0:00
[btrfs-endio-met]
root 8384 0.0 0.0 73936 884 ? D 16:42 0:00 ls
--color=tty /root/linjian/mnt_btrfs
root 8490 0.0 0.0 0 0 ? S 17:10 0:00 [flush-btrfs-1]
root 8517 0.0 0.0 61192 736 pts/6 S+ 17:14 0:00 grep btrfs
Maybe it's a bug of fstest. I will review it's code.
However, I don't think a bad user-space program will make file system
no-responding.
Would you please show me some suggestions on this problem.
Thanks!
--
Jian Lin
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: BtrFS does not respond after doing 'fstest' on both original and cloned file
2009-12-09 1:53 BtrFS does not respond after doing 'fstest' on both original and cloned file Jian Lin
@ 2009-12-09 2:19 ` Yan, Zheng
2009-12-09 3:55 ` Jian Lin
2009-12-09 2:19 ` Zhang Jingwang
1 sibling, 1 reply; 7+ messages in thread
From: Yan, Zheng @ 2009-12-09 2:19 UTC (permalink / raw)
To: Jian Lin; +Cc: linux-btrfs
On Wed, Dec 9, 2009 at 9:53 AM, Jian Lin <mail@linjian.org> wrote:
> Hi,
>
> I am using Linux 2.6.32 on X86_64 with BtrFS compiled in the kernel.
> For my experimental application, I want to evaluate reliability of CO=
W
> feature of BtrFS.
> I chose a small tool called fstest (http://code.google.com/p/fstest/)
> and modified it:
>
> [root@node34 fstest-0.1.3]# diff fstest.c fstest-mod.c
> 315c315
> < =A0 =A0 unlink(p->filename);
> ---
>> =A0 =A0 //unlink(p->filename);
> 317c317
> < =A0 =A0 *file=3Dopen(p->filename, O_RDWR|O_CREAT|O_EXCL, 0777);
> ---
>> =A0 =A0 *file=3Dopen(p->filename, O_RDWR|O_CREAT/*|O_EXCL*/, 0777);
> 360c360
> < =A0 =A0 unlink(p.filename);
> ---
>> =A0 =A0 //unlink(p.filename);
>
> So, fstest-mod will ramdomly write and read blocks in a specific file=
,
> and check whether it is consistent.
> Then I made a zero-filled file and a clone of it, ran fstest-mod
> respectively on the original and the cloned file:
>
> dd if=3D/dev/zero of=3Dtestbase bs=3D100 count=3D$((1024*1024))
> cp --reflink testbase testbase-ref
> [One Terminal] ./fstest-mod testbase $((100*1024*1024))
> [Another Terminal] ./fstest-mod testbase-ref $((100*1024*1024))
>
> When the test files were small (~100M), both fstest-mod programs retu=
rned OK.
> However, when I used bigger test files (2G), BtrFS did not respond
> after a period of time.
> It said:
>
> Message from syslogd@ at Wed Dec =A09 08:38:42 2009 ...
> node34 kernel: ------------[ cut here ]------------
> Message from syslogd@ at Wed Dec =A09 08:38:42 2009 ...
> node34 kernel: invalid opcode: 0000 [#1] SMP
> Message from syslogd@ at Wed Dec =A09 08:38:42 2009 ...
> node34 kernel: last sysfs file:
> /sys/devices/system/cpu/cpu3/cache/index1/shared_cpu_map
> Message from syslogd@ at Wed Dec =A09 08:38:42 2009 ...
> node34 kernel: Stack:
> Message from syslogd@ at Wed Dec =A09 08:38:42 2009 ...
> node34 kernel: Call Trace:
> Message from syslogd@ at Wed Dec =A09 08:38:42 2009 ...
> node34 kernel: Code: 24 10 4c 89 f6 e8 5a 16 fc ff 48 8b 7c 24 20 eb
> 29 48 8d 6b f0 48 8b 74 24 10 48 8b 7c 24 18 48 89 ea e8 00 4b fd ff
> 85 c0 74 04 <0f> 0b eb fe 48 89 df e8 c2 a9 05 00 48 89 ef e8 d2 93 f=
5
> ff 48
>
Please send full messages of this oops, you can find them in /var/log/m=
essages.
Regards
Yan Zheng
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: BtrFS does not respond after doing 'fstest' on both original and cloned file
2009-12-09 1:53 BtrFS does not respond after doing 'fstest' on both original and cloned file Jian Lin
2009-12-09 2:19 ` Yan, Zheng
@ 2009-12-09 2:19 ` Zhang Jingwang
2009-12-09 4:11 ` Jian Lin
1 sibling, 1 reply; 7+ messages in thread
From: Zhang Jingwang @ 2009-12-09 2:19 UTC (permalink / raw)
To: Jian Lin; +Cc: linux-btrfs
More information is appreciated. btrfs-show's output, configuration
info, related dmesg output and so on..
2009/12/9 Jian Lin <mail@linjian.org>:
> Hi,
>
> I am using Linux 2.6.32 on X86_64 with BtrFS compiled in the kernel.
> For my experimental application, I want to evaluate reliability of CO=
W
> feature of BtrFS.
> I chose a small tool called fstest (http://code.google.com/p/fstest/)
> and modified it:
>
> [root@node34 fstest-0.1.3]# diff fstest.c fstest-mod.c
> 315c315
> < =A0 =A0 unlink(p->filename);
> ---
>> =A0 =A0 //unlink(p->filename);
> 317c317
> < =A0 =A0 *file=3Dopen(p->filename, O_RDWR|O_CREAT|O_EXCL, 0777);
> ---
>> =A0 =A0 *file=3Dopen(p->filename, O_RDWR|O_CREAT/*|O_EXCL*/, 0777);
> 360c360
> < =A0 =A0 unlink(p.filename);
> ---
>> =A0 =A0 //unlink(p.filename);
>
> So, fstest-mod will ramdomly write and read blocks in a specific file=
,
> and check whether it is consistent.
> Then I made a zero-filled file and a clone of it, ran fstest-mod
> respectively on the original and the cloned file:
>
> dd if=3D/dev/zero of=3Dtestbase bs=3D100 count=3D$((1024*1024))
> cp --reflink testbase testbase-ref
> [One Terminal] ./fstest-mod testbase $((100*1024*1024))
> [Another Terminal] ./fstest-mod testbase-ref $((100*1024*1024))
>
> When the test files were small (~100M), both fstest-mod programs retu=
rned OK.
> However, when I used bigger test files (2G), BtrFS did not respond
> after a period of time.
> It said:
>
> Message from syslogd@ at Wed Dec =A09 08:38:42 2009 ...
> node34 kernel: ------------[ cut here ]------------
> Message from syslogd@ at Wed Dec =A09 08:38:42 2009 ...
> node34 kernel: invalid opcode: 0000 [#1] SMP
> Message from syslogd@ at Wed Dec =A09 08:38:42 2009 ...
> node34 kernel: last sysfs file:
> /sys/devices/system/cpu/cpu3/cache/index1/shared_cpu_map
> Message from syslogd@ at Wed Dec =A09 08:38:42 2009 ...
> node34 kernel: Stack:
> Message from syslogd@ at Wed Dec =A09 08:38:42 2009 ...
> node34 kernel: Call Trace:
> Message from syslogd@ at Wed Dec =A09 08:38:42 2009 ...
> node34 kernel: Code: 24 10 4c 89 f6 e8 5a 16 fc ff 48 8b 7c 24 20 eb
> 29 48 8d 6b f0 48 8b 74 24 10 48 8b 7c 24 18 48 89 ea e8 00 4b fd ff
> 85 c0 74 04 <0f> 0b eb fe 48 89 df e8 c2 a9 05 00 48 89 ef e8 d2 93 f=
5
> ff 48
>
> [root@node34 ~]# cat /sys/devices/system/cpu/cpu3/cache/index1/shared=
_cpu_map
> 00000000,00000000,00000000,00000000,00000000,00000000,00000000,000000=
0a
> [root@node34 ~]# ps aux | grep fstest
> root =A0 =A0 =A07352 =A00.7 =A00.0 =A0 3792 =A0 456 pts/3 =A0 =A0D+ =A0=
08:24 =A0 3:55
> ./fstest-mod testbase 2147483648
> root =A0 =A0 =A08420 =A00.0 =A00.0 =A061192 =A0 740 pts/6 =A0 =A0S+ =A0=
16:44 =A0 0:00 grep fstest
>
> When I tried to list files on BtrFS, ls process also hanged:
>
> [root@node34 ~]# ps aux | grep ls
> root =A0 =A0 =A08290 =A00.0 =A00.0 =A073936 =A0 884 pts/1 =A0 =A0D+ =A0=
16:34 =A0 0:00 ls --color=3Dtty
> root =A0 =A0 =A08327 =A00.0 =A00.0 =A073936 =A0 884 ? =A0 =A0 =A0 =A0=
D =A0 =A016:35 =A0 0:00 ls --color=3Dtty
> root =A0 =A0 =A08384 =A00.0 =A00.0 =A073936 =A0 884 pts/5 =A0 =A0D+ =A0=
16:42 =A0 0:00 ls
> --color=3Dtty /root/linjian/mnt_btrfs
> root =A0 =A0 =A08422 =A00.0 =A00.0 =A061192 =A0 736 pts/6 =A0 =A0S+ =A0=
16:44 =A0 0:00 grep ls
>
> [root@node34 ~]# ps aux | grep btrfs
> root =A0 =A0 =A03967 =A00.0 =A00.0 =A0 =A0 =A00 =A0 =A0 0 ? =A0 =A0 =A0=
=A0S =A0 =A0Dec08 =A0 0:00
> [btrfs-genwork-0]
> root =A0 =A0 =A03968 =A00.0 =A00.0 =A0 =A0 =A00 =A0 =A0 0 ? =A0 =A0 =A0=
=A0S =A0 =A0Dec08 =A0 0:39
> [btrfs-submit-0]
> root =A0 =A0 =A03969 =A00.0 =A00.0 =A0 =A0 =A00 =A0 =A0 0 ? =A0 =A0 =A0=
=A0S =A0 =A0Dec08 =A0 0:00
> [btrfs-delalloc-]
> root =A0 =A0 =A03970 =A00.0 =A00.0 =A0 =A0 =A00 =A0 =A0 0 ? =A0 =A0 =A0=
=A0S =A0 =A0Dec08 =A0 0:00 [btrfs-fixup-0]
> root =A0 =A0 =A03975 =A00.0 =A00.0 =A0 =A0 =A00 =A0 =A0 0 ? =A0 =A0 =A0=
=A0S =A0 =A0Dec08 =A0 0:00
> [btrfs-enospc-0]
> root =A0 =A0 =A03976 =A00.0 =A00.0 =A0 =A0 =A00 =A0 =A0 0 ? =A0 =A0 =A0=
=A0S =A0 =A0Dec08 =A0 0:00 [btrfs-cleaner]
> root =A0 =A0 =A03977 =A00.0 =A00.0 =A0 =A0 =A00 =A0 =A0 0 ? =A0 =A0 =A0=
=A0D =A0 =A0Dec08 =A0 0:04
> [btrfs-transacti]
> root =A0 =A0 =A04301 =A00.2 =A00.0 =A0 =A0 =A00 =A0 =A0 0 ? =A0 =A0 =A0=
=A0S =A0 =A0Dec08 =A0 3:11
> [btrfs-endio-wri]
> root =A0 =A0 =A04461 =A00.7 =A00.0 =A0 =A0 =A00 =A0 =A0 0 ? =A0 =A0 =A0=
=A0S =A0 =A0Dec08 =A0 8:55
> [btrfs-worker-1]
> root =A0 =A0 =A04495 =A00.0 =A00.0 =A0 =A0 =A00 =A0 =A0 0 ? =A0 =A0 =A0=
=A0S =A0 =A0Dec08 =A0 0:20
> [btrfs-endio-met]
> root =A0 =A0 =A04601 =A00.0 =A00.0 =A0 =A0 =A00 =A0 =A0 0 ? =A0 =A0 =A0=
=A0S =A0 =A0Dec08 =A0 0:34 [btrfs-endio-1]
> root =A0 =A0 =A04623 =A00.0 =A00.0 =A0 =A0 =A00 =A0 =A0 0 ? =A0 =A0 =A0=
=A0S =A0 =A0Dec08 =A0 0:00
> [btrfs-endio-met]
> root =A0 =A0 =A08384 =A00.0 =A00.0 =A073936 =A0 884 ? =A0 =A0 =A0 =A0=
D =A0 =A016:42 =A0 0:00 ls
> --color=3Dtty /root/linjian/mnt_btrfs
> root =A0 =A0 =A08490 =A00.0 =A00.0 =A0 =A0 =A00 =A0 =A0 0 ? =A0 =A0 =A0=
=A0S =A0 =A017:10 =A0 0:00 [flush-btrfs-1]
> root =A0 =A0 =A08517 =A00.0 =A00.0 =A061192 =A0 736 pts/6 =A0 =A0S+ =A0=
17:14 =A0 0:00 grep btrfs
>
> Maybe it's a bug of fstest. I will review it's code.
> However, I don't think a bad user-space program will make file system
> no-responding.
>
> Would you please show me some suggestions on this problem.
> Thanks!
>
> --
> Jian Lin
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs=
" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at =A0http://vger.kernel.org/majordomo-info.html
>
--=20
Zhang Jingwang
National Research Centre for High Performance Computers
Institute of Computing Technology, Chinese Academy of Sciences
No. 6, South Kexueyuan Road, Haidian District
Beijing, China
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: BtrFS does not respond after doing 'fstest' on both original and cloned file
2009-12-09 2:19 ` Yan, Zheng
@ 2009-12-09 3:55 ` Jian Lin
2009-12-09 5:01 ` Yan, Zheng
0 siblings, 1 reply; 7+ messages in thread
From: Jian Lin @ 2009-12-09 3:55 UTC (permalink / raw)
To: Yan, Zheng; +Cc: linux-btrfs
=46ull msg in /var/log/messages:
Dec 9 08:38:42 node34 kernel: ------------[ cut here ]------------
Dec 9 08:38:42 node34 kernel: kernel BUG at fs/btrfs/tree-log.c:2661!
Dec 9 08:38:42 node34 kernel: invalid opcode: 0000 [#1] SMP
Dec 9 08:38:42 node34 kernel: last sysfs file:
/sys/devices/system/cpu/cpu3/cache/index1/shared_cpu_map
Dec 9 08:38:42 node34 kernel: CPU 0
Dec 9 08:38:42 node34 kernel: Modules linked in: nls_utf8 hfsplus
autofs4 i2c_dev i2c_core sunrpc dm_mirror dm_multipath scsi_dh video
output sbs sbshc battery acpi_memhotplug ac ipv6 parport_pc lp parport
joydev ide_cd_mod cdrom serio_raw floppy button tg3 libphy hpilo
ata_piix libata e752x_edac rtc_cmos edac_core rtc_core rtc_lib pcspkr
dm_region_hash dm_log dm_mod shpchp cciss sd_mod scsi_mod ext3 jbd
uhci_hcd ohci_hcd ehci_hcd [last unloaded: freq_table]
Dec 9 08:38:42 node34 kernel: Pid: 7354, comm: fstest-mod Not tainted
2.6.32 #1 ProLiant DL380 G4
Dec 9 08:38:42 node34 kernel: RIP: 0010:[<ffffffff81168606>]
[<ffffffff81168606>] copy_items+0x2c2/0x2ff
Dec 9 08:38:42 node34 kernel: RSP: 0018:ffff880001fdfcb8 EFLAGS: 0001=
0282
Dec 9 08:38:42 node34 kernel: RAX: 00000000ffffffef RBX:
ffff88005d494010 RCX: 0000000000000000
Dec 9 08:38:42 node34 kernel: RDX: 0000000000000003 RSI:
ffff88007ab10250 RDI: ffff88007e657240
Dec 9 08:38:42 node34 kernel: RBP: ffff88005d494000 R08:
ffff880001fdfa28 R09: ffff880001fdfa20
Dec 9 08:38:42 node34 kernel: R10: 000000011b982800 R11:
ffff88005a138ce0 R12: 0000000000196000
Dec 9 08:38:42 node34 kernel: R13: ffff88006df62370 R14:
ffff88007ab10370 R15: 000000000c302000
Dec 9 08:38:42 node34 kernel: FS: 00007fccfb4ba6e0(0000)
GS:ffff880003c00000(0000) knlGS:0000000000000000
Dec 9 08:38:42 node34 kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000=
08005003b
Dec 9 08:38:42 node34 kernel: CR2: 0000000000f58000 CR3:
0000000045fbe000 CR4: 00000000000006f0
Dec 9 08:38:42 node34 kernel: DR0: 0000000000000000 DR1:
0000000000000000 DR2: 0000000000000000
Dec 9 08:38:42 node34 kernel: DR3: 0000000000000000 DR6:
00000000ffff0ff0 DR7: 0000000000000400
Dec 9 08:38:42 node34 kernel: Process fstest-mod (pid: 7354,
threadinfo ffff880001fde000, task ffff88007f10c870)
Dec 9 08:38:42 node34 kernel: Stack:
Dec 9 08:38:42 node34 kernel: ffff88007ab102e0 0000003300000000
ffff88001b982800 ffff88005a138ce0
Dec 9 08:38:42 node34 kernel: <0> ffff8800594e2000 0000003300000547
000000034b163000 ffff8800594e242f
Dec 9 08:38:42 node34 kernel: <0> 0000000000000560 0000000000000065
ffff8800594e20cc 000000338115061d
Dec 9 08:38:42 node34 kernel: Call Trace:
Dec 9 08:38:42 node34 kernel: [<ffffffff81169273>] ?
btrfs_log_inode+0x32c/0x467
Dec 9 08:38:42 node34 kernel: [<ffffffff81146000>] ? btrfs_writepage+=
0x0/0x4e
Dec 9 08:38:42 node34 kernel: [<ffffffff81169587>] ?
btrfs_log_inode_parent+0x1d9/0x2a7
Dec 9 08:38:42 node34 kernel: [<ffffffff8114cc59>] ?
btrfs_sync_file+0xd6/0x14d
Dec 9 08:38:42 node34 kernel: [<ffffffff810e4456>] ? vfs_fsync_range+=
0x73/0x9e
Dec 9 08:38:42 node34 kernel: [<ffffffff810e44ff>] ? do_fsync+0x27/0x=
3a
Dec 9 08:38:42 node34 kernel: [<ffffffff810e4530>] ? sys_fsync+0xb/0x=
10
Dec 9 08:38:42 node34 kernel: [<ffffffff8100b8eb>] ?
system_call_fastpath+0x16/0x1b
Dec 9 08:38:42 node34 kernel: Code: 24 10 4c 89 f6 e8 5a 16 fc ff 48
8b 7c 24 20 eb 29 48 8d 6b f0 48 8b 74 24 10 48 8b 7c 24 18 48 89 ea
e8 00 4b fd ff 85 c0 74 04 <0f> 0b eb fe 48 89 df e8 c2 a9 05 00 48 89
ef e8 d2 93 f5 ff 48
Dec 9 08:38:42 node34 kernel: RIP [<ffffffff81168606>] copy_items+0x2=
c2/0x2ff
Dec 9 08:38:42 node34 kernel: RSP <ffff880001fdfcb8>
Dec 9 08:38:42 node34 kernel: ---[ end trace 3ea0fce179abe088 ]---
On Wed, Dec 9, 2009 at 10:19 AM, Yan, Zheng <yanzheng@21cn.com> wrote:
> On Wed, Dec 9, 2009 at 9:53 AM, Jian Lin <mail@linjian.org> wrote:
>> Hi,
>>
>> I am using Linux 2.6.32 on X86_64 with BtrFS compiled in the kernel.
>> For my experimental application, I want to evaluate reliability of C=
OW
>> feature of BtrFS.
>> I chose a small tool called fstest (http://code.google.com/p/fstest/=
)
>> and modified it:
>>
>> [root@node34 fstest-0.1.3]# diff fstest.c fstest-mod.c
>> 315c315
>> < =A0 =A0 unlink(p->filename);
>> ---
>>> =A0 =A0 //unlink(p->filename);
>> 317c317
>> < =A0 =A0 *file=3Dopen(p->filename, O_RDWR|O_CREAT|O_EXCL, 0777);
>> ---
>>> =A0 =A0 *file=3Dopen(p->filename, O_RDWR|O_CREAT/*|O_EXCL*/, 0777);
>> 360c360
>> < =A0 =A0 unlink(p.filename);
>> ---
>>> =A0 =A0 //unlink(p.filename);
>>
>> So, fstest-mod will ramdomly write and read blocks in a specific fil=
e,
>> and check whether it is consistent.
>> Then I made a zero-filled file and a clone of it, ran fstest-mod
>> respectively on the original and the cloned file:
>>
>> dd if=3D/dev/zero of=3Dtestbase bs=3D100 count=3D$((1024*1024))
>> cp --reflink testbase testbase-ref
>> [One Terminal] ./fstest-mod testbase $((100*1024*1024))
>> [Another Terminal] ./fstest-mod testbase-ref $((100*1024*1024))
>>
>> When the test files were small (~100M), both fstest-mod programs ret=
urned OK.
>> However, when I used bigger test files (2G), BtrFS did not respond
>> after a period of time.
>> It said:
>>
>> Message from syslogd@ at Wed Dec =A09 08:38:42 2009 ...
>> node34 kernel: ------------[ cut here ]------------
>> Message from syslogd@ at Wed Dec =A09 08:38:42 2009 ...
>> node34 kernel: invalid opcode: 0000 [#1] SMP
>> Message from syslogd@ at Wed Dec =A09 08:38:42 2009 ...
>> node34 kernel: last sysfs file:
>> /sys/devices/system/cpu/cpu3/cache/index1/shared_cpu_map
>> Message from syslogd@ at Wed Dec =A09 08:38:42 2009 ...
>> node34 kernel: Stack:
>> Message from syslogd@ at Wed Dec =A09 08:38:42 2009 ...
>> node34 kernel: Call Trace:
>> Message from syslogd@ at Wed Dec =A09 08:38:42 2009 ...
>> node34 kernel: Code: 24 10 4c 89 f6 e8 5a 16 fc ff 48 8b 7c 24 20 eb
>> 29 48 8d 6b f0 48 8b 74 24 10 48 8b 7c 24 18 48 89 ea e8 00 4b fd ff
>> 85 c0 74 04 <0f> 0b eb fe 48 89 df e8 c2 a9 05 00 48 89 ef e8 d2 93 =
f5
>> ff 48
>>
>
> Please send full messages of this oops, you can find them in /var/log=
/messages.
>
> Regards
> Yan Zheng
>
--=20
Jian Lin
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: BtrFS does not respond after doing 'fstest' on both original and cloned file
2009-12-09 2:19 ` Zhang Jingwang
@ 2009-12-09 4:11 ` Jian Lin
0 siblings, 0 replies; 7+ messages in thread
From: Jian Lin @ 2009-12-09 4:11 UTC (permalink / raw)
To: Zhang Jingwang; +Cc: linux-btrfs
On Wed, Dec 9, 2009 at 10:19 AM, Zhang Jingwang <yyalone@gmail.com> wro=
te:
> More information is appreciated. btrfs-show's output, configuration
> info, related dmesg output and so on..
/var/log/messages was posted in my last mail.
btrfs-show failed. my BtrFS is on /dev/cciss/c0d0p3:
[root@node34 fstest-0.1.3]# btrfs-show /dev/cciss/c0d0p3
failed to read /dev/hda
Output of btrfs-debug-tree: http://jian.me/u/btrfs-debug-tree.c0d0p3.tx=
t.zip
To Zhang: BTW, I am also at ICT, CAS.
>
> 2009/12/9 Jian Lin <mail@linjian.org>:
>> Hi,
>>
>> I am using Linux 2.6.32 on X86_64 with BtrFS compiled in the kernel.
>> For my experimental application, I want to evaluate reliability of C=
OW
>> feature of BtrFS.
>> I chose a small tool called fstest (http://code.google.com/p/fstest/=
)
>> and modified it:
>>
>> [root@node34 fstest-0.1.3]# diff fstest.c fstest-mod.c
>> 315c315
>> < =A0 =A0 unlink(p->filename);
>> ---
>>> =A0 =A0 //unlink(p->filename);
>> 317c317
>> < =A0 =A0 *file=3Dopen(p->filename, O_RDWR|O_CREAT|O_EXCL, 0777);
>> ---
>>> =A0 =A0 *file=3Dopen(p->filename, O_RDWR|O_CREAT/*|O_EXCL*/, 0777);
>> 360c360
>> < =A0 =A0 unlink(p.filename);
>> ---
>>> =A0 =A0 //unlink(p.filename);
>>
>> So, fstest-mod will ramdomly write and read blocks in a specific fil=
e,
>> and check whether it is consistent.
>> Then I made a zero-filled file and a clone of it, ran fstest-mod
>> respectively on the original and the cloned file:
>>
>> dd if=3D/dev/zero of=3Dtestbase bs=3D100 count=3D$((1024*1024))
>> cp --reflink testbase testbase-ref
>> [One Terminal] ./fstest-mod testbase $((100*1024*1024))
>> [Another Terminal] ./fstest-mod testbase-ref $((100*1024*1024))
>>
>> When the test files were small (~100M), both fstest-mod programs ret=
urned OK.
>> However, when I used bigger test files (2G), BtrFS did not respond
>> after a period of time.
>> It said:
>>
>> Message from syslogd@ at Wed Dec =A09 08:38:42 2009 ...
>> node34 kernel: ------------[ cut here ]------------
>> Message from syslogd@ at Wed Dec =A09 08:38:42 2009 ...
>> node34 kernel: invalid opcode: 0000 [#1] SMP
>> Message from syslogd@ at Wed Dec =A09 08:38:42 2009 ...
>> node34 kernel: last sysfs file:
>> /sys/devices/system/cpu/cpu3/cache/index1/shared_cpu_map
>> Message from syslogd@ at Wed Dec =A09 08:38:42 2009 ...
>> node34 kernel: Stack:
>> Message from syslogd@ at Wed Dec =A09 08:38:42 2009 ...
>> node34 kernel: Call Trace:
>> Message from syslogd@ at Wed Dec =A09 08:38:42 2009 ...
>> node34 kernel: Code: 24 10 4c 89 f6 e8 5a 16 fc ff 48 8b 7c 24 20 eb
>> 29 48 8d 6b f0 48 8b 74 24 10 48 8b 7c 24 18 48 89 ea e8 00 4b fd ff
>> 85 c0 74 04 <0f> 0b eb fe 48 89 df e8 c2 a9 05 00 48 89 ef e8 d2 93 =
f5
>> ff 48
>>
>> [root@node34 ~]# cat /sys/devices/system/cpu/cpu3/cache/index1/share=
d_cpu_map
>> 00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000=
00a
>> [root@node34 ~]# ps aux | grep fstest
>> root =A0 =A0 =A07352 =A00.7 =A00.0 =A0 3792 =A0 456 pts/3 =A0 =A0D+ =
=A0 08:24 =A0 3:55
>> ./fstest-mod testbase 2147483648
>> root =A0 =A0 =A08420 =A00.0 =A00.0 =A061192 =A0 740 pts/6 =A0 =A0S+ =
=A0 16:44 =A0 0:00 grep fstest
>>
>> When I tried to list files on BtrFS, ls process also hanged:
>>
>> [root@node34 ~]# ps aux | grep ls
>> root =A0 =A0 =A08290 =A00.0 =A00.0 =A073936 =A0 884 pts/1 =A0 =A0D+ =
=A0 16:34 =A0 0:00 ls --color=3Dtty
>> root =A0 =A0 =A08327 =A00.0 =A00.0 =A073936 =A0 884 ? =A0 =A0 =A0 =A0=
D =A0 =A016:35 =A0 0:00 ls --color=3Dtty
>> root =A0 =A0 =A08384 =A00.0 =A00.0 =A073936 =A0 884 pts/5 =A0 =A0D+ =
=A0 16:42 =A0 0:00 ls
>> --color=3Dtty /root/linjian/mnt_btrfs
>> root =A0 =A0 =A08422 =A00.0 =A00.0 =A061192 =A0 736 pts/6 =A0 =A0S+ =
=A0 16:44 =A0 0:00 grep ls
>>
>> [root@node34 ~]# ps aux | grep btrfs
>> root =A0 =A0 =A03967 =A00.0 =A00.0 =A0 =A0 =A00 =A0 =A0 0 ? =A0 =A0 =
=A0 =A0S =A0 =A0Dec08 =A0 0:00
>> [btrfs-genwork-0]
>> root =A0 =A0 =A03968 =A00.0 =A00.0 =A0 =A0 =A00 =A0 =A0 0 ? =A0 =A0 =
=A0 =A0S =A0 =A0Dec08 =A0 0:39
>> [btrfs-submit-0]
>> root =A0 =A0 =A03969 =A00.0 =A00.0 =A0 =A0 =A00 =A0 =A0 0 ? =A0 =A0 =
=A0 =A0S =A0 =A0Dec08 =A0 0:00
>> [btrfs-delalloc-]
>> root =A0 =A0 =A03970 =A00.0 =A00.0 =A0 =A0 =A00 =A0 =A0 0 ? =A0 =A0 =
=A0 =A0S =A0 =A0Dec08 =A0 0:00 [btrfs-fixup-0]
>> root =A0 =A0 =A03975 =A00.0 =A00.0 =A0 =A0 =A00 =A0 =A0 0 ? =A0 =A0 =
=A0 =A0S =A0 =A0Dec08 =A0 0:00
>> [btrfs-enospc-0]
>> root =A0 =A0 =A03976 =A00.0 =A00.0 =A0 =A0 =A00 =A0 =A0 0 ? =A0 =A0 =
=A0 =A0S =A0 =A0Dec08 =A0 0:00 [btrfs-cleaner]
>> root =A0 =A0 =A03977 =A00.0 =A00.0 =A0 =A0 =A00 =A0 =A0 0 ? =A0 =A0 =
=A0 =A0D =A0 =A0Dec08 =A0 0:04
>> [btrfs-transacti]
>> root =A0 =A0 =A04301 =A00.2 =A00.0 =A0 =A0 =A00 =A0 =A0 0 ? =A0 =A0 =
=A0 =A0S =A0 =A0Dec08 =A0 3:11
>> [btrfs-endio-wri]
>> root =A0 =A0 =A04461 =A00.7 =A00.0 =A0 =A0 =A00 =A0 =A0 0 ? =A0 =A0 =
=A0 =A0S =A0 =A0Dec08 =A0 8:55
>> [btrfs-worker-1]
>> root =A0 =A0 =A04495 =A00.0 =A00.0 =A0 =A0 =A00 =A0 =A0 0 ? =A0 =A0 =
=A0 =A0S =A0 =A0Dec08 =A0 0:20
>> [btrfs-endio-met]
>> root =A0 =A0 =A04601 =A00.0 =A00.0 =A0 =A0 =A00 =A0 =A0 0 ? =A0 =A0 =
=A0 =A0S =A0 =A0Dec08 =A0 0:34 [btrfs-endio-1]
>> root =A0 =A0 =A04623 =A00.0 =A00.0 =A0 =A0 =A00 =A0 =A0 0 ? =A0 =A0 =
=A0 =A0S =A0 =A0Dec08 =A0 0:00
>> [btrfs-endio-met]
>> root =A0 =A0 =A08384 =A00.0 =A00.0 =A073936 =A0 884 ? =A0 =A0 =A0 =A0=
D =A0 =A016:42 =A0 0:00 ls
>> --color=3Dtty /root/linjian/mnt_btrfs
>> root =A0 =A0 =A08490 =A00.0 =A00.0 =A0 =A0 =A00 =A0 =A0 0 ? =A0 =A0 =
=A0 =A0S =A0 =A017:10 =A0 0:00 [flush-btrfs-1]
>> root =A0 =A0 =A08517 =A00.0 =A00.0 =A061192 =A0 736 pts/6 =A0 =A0S+ =
=A0 17:14 =A0 0:00 grep btrfs
>>
>> Maybe it's a bug of fstest. I will review it's code.
>> However, I don't think a bad user-space program will make file syste=
m
>> no-responding.
>>
>> Would you please show me some suggestions on this problem.
>> Thanks!
>>
>> --
>> Jian Lin
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-btrf=
s" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at =A0http://vger.kernel.org/majordomo-info.html
>>
>
>
>
> --
> Zhang Jingwang
> National Research Centre for High Performance Computers
> Institute of Computing Technology, Chinese Academy of Sciences
> No. 6, South Kexueyuan Road, Haidian District
> Beijing, China
>
--=20
Jian Lin
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: BtrFS does not respond after doing 'fstest' on both original and cloned file
2009-12-09 3:55 ` Jian Lin
@ 2009-12-09 5:01 ` Yan, Zheng
2009-12-09 9:09 ` Jian Lin
0 siblings, 1 reply; 7+ messages in thread
From: Yan, Zheng @ 2009-12-09 5:01 UTC (permalink / raw)
To: Jian Lin; +Cc: linux-btrfs
On Wed, Dec 9, 2009 at 11:55 AM, Jian Lin <mail@linjian.org> wrote:
> Full msg in /var/log/messages:
> Dec =A09 08:38:42 node34 kernel: ------------[ cut here ]------------
> Dec =A09 08:38:42 node34 kernel: kernel BUG at fs/btrfs/tree-log.c:26=
61!
> Dec =A09 08:38:42 node34 kernel: invalid opcode: 0000 [#1] SMP
> Dec =A09 08:38:42 node34 kernel: last sysfs file:
> /sys/devices/system/cpu/cpu3/cache/index1/shared_cpu_map
> Dec =A09 08:38:42 node34 kernel: CPU 0
> Dec =A09 08:38:42 node34 kernel: Modules linked in: nls_utf8 hfsplus
> autofs4 i2c_dev i2c_core sunrpc dm_mirror dm_multipath scsi_dh video
> output sbs sbshc battery acpi_memhotplug ac ipv6 parport_pc lp parpor=
t
> joydev ide_cd_mod cdrom serio_raw floppy button tg3 libphy hpilo
> ata_piix libata e752x_edac rtc_cmos edac_core rtc_core rtc_lib pcspkr
> dm_region_hash dm_log dm_mod shpchp cciss sd_mod scsi_mod ext3 jbd
> uhci_hcd ohci_hcd ehci_hcd [last unloaded: freq_table]
> Dec =A09 08:38:42 node34 kernel: Pid: 7354, comm: fstest-mod Not tain=
ted
> 2.6.32 #1 ProLiant DL380 G4
> Dec =A09 08:38:42 node34 kernel: RIP: 0010:[<ffffffff81168606>]
> [<ffffffff81168606>] copy_items+0x2c2/0x2ff
> Dec =A09 08:38:42 node34 kernel: RSP: 0018:ffff880001fdfcb8 =A0EFLAGS=
: 00010282
> Dec =A09 08:38:42 node34 kernel: RAX: 00000000ffffffef RBX:
> ffff88005d494010 RCX: 0000000000000000
> Dec =A09 08:38:42 node34 kernel: RDX: 0000000000000003 RSI:
> ffff88007ab10250 RDI: ffff88007e657240
> Dec =A09 08:38:42 node34 kernel: RBP: ffff88005d494000 R08:
> ffff880001fdfa28 R09: ffff880001fdfa20
> Dec =A09 08:38:42 node34 kernel: R10: 000000011b982800 R11:
> ffff88005a138ce0 R12: 0000000000196000
> Dec =A09 08:38:42 node34 kernel: R13: ffff88006df62370 R14:
> ffff88007ab10370 R15: 000000000c302000
> Dec =A09 08:38:42 node34 kernel: FS: =A000007fccfb4ba6e0(0000)
> GS:ffff880003c00000(0000) knlGS:0000000000000000
> Dec =A09 08:38:42 node34 kernel: CS: =A00010 DS: 0000 ES: 0000 CR0: 0=
00000008005003b
> Dec =A09 08:38:42 node34 kernel: CR2: 0000000000f58000 CR3:
> 0000000045fbe000 CR4: 00000000000006f0
> Dec =A09 08:38:42 node34 kernel: DR0: 0000000000000000 DR1:
> 0000000000000000 DR2: 0000000000000000
> Dec =A09 08:38:42 node34 kernel: DR3: 0000000000000000 DR6:
> 00000000ffff0ff0 DR7: 0000000000000400
> Dec =A09 08:38:42 node34 kernel: Process fstest-mod (pid: 7354,
> threadinfo ffff880001fde000, task ffff88007f10c870)
> Dec =A09 08:38:42 node34 kernel: Stack:
> Dec =A09 08:38:42 node34 kernel: =A0ffff88007ab102e0 0000003300000000
> ffff88001b982800 ffff88005a138ce0
> Dec =A09 08:38:42 node34 kernel: <0> ffff8800594e2000 000000330000054=
7
> 000000034b163000 ffff8800594e242f
> Dec =A09 08:38:42 node34 kernel: <0> 0000000000000560 000000000000006=
5
> ffff8800594e20cc 000000338115061d
> Dec =A09 08:38:42 node34 kernel: Call Trace:
> Dec =A09 08:38:42 node34 kernel: =A0[<ffffffff81169273>] ?
> btrfs_log_inode+0x32c/0x467
> Dec =A09 08:38:42 node34 kernel: =A0[<ffffffff81146000>] ? btrfs_writ=
epage+0x0/0x4e
> Dec =A09 08:38:42 node34 kernel: =A0[<ffffffff81169587>] ?
> btrfs_log_inode_parent+0x1d9/0x2a7
> Dec =A09 08:38:42 node34 kernel: =A0[<ffffffff8114cc59>] ?
> btrfs_sync_file+0xd6/0x14d
> Dec =A09 08:38:42 node34 kernel: =A0[<ffffffff810e4456>] ? vfs_fsync_=
range+0x73/0x9e
> Dec =A09 08:38:42 node34 kernel: =A0[<ffffffff810e44ff>] ? do_fsync+0=
x27/0x3a
> Dec =A09 08:38:42 node34 kernel: =A0[<ffffffff810e4530>] ? sys_fsync+=
0xb/0x10
> Dec =A09 08:38:42 node34 kernel: =A0[<ffffffff8100b8eb>] ?
> system_call_fastpath+0x16/0x1b
> Dec =A09 08:38:42 node34 kernel: Code: 24 10 4c 89 f6 e8 5a 16 fc ff =
48
> 8b 7c 24 20 eb 29 48 8d 6b f0 48 8b 74 24 10 48 8b 7c 24 18 48 89 ea
> e8 00 4b fd ff 85 c0 74 04 <0f> 0b eb fe 48 89 df e8 c2 a9 05 00 48 8=
9
> ef e8 d2 93 f5 ff 48
> Dec =A09 08:38:42 node34 kernel: RIP =A0[<ffffffff81168606>] copy_ite=
ms+0x2c2/0x2ff
> Dec =A09 08:38:42 node34 kernel: =A0RSP <ffff880001fdfcb8>
> Dec =A09 08:38:42 node34 kernel: ---[ end trace 3ea0fce179abe088 ]---
btrfs_csum_file_blocks return -EEXIST, looks like a race.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: BtrFS does not respond after doing 'fstest' on both original and cloned file
2009-12-09 5:01 ` Yan, Zheng
@ 2009-12-09 9:09 ` Jian Lin
0 siblings, 0 replies; 7+ messages in thread
From: Jian Lin @ 2009-12-09 9:09 UTC (permalink / raw)
To: Yan, Zheng; +Cc: linux-btrfs
This problem can be reproduced on both my Dell and HP servers (X86_64,
CentOS5, 2.6.32) when test file is 2G or larger, and the error
messages are almost the same everytime. (about syslogd,
fs/btrfs/tree-log.c)
On Wed, Dec 9, 2009 at 1:01 PM, Yan, Zheng <yanzheng@21cn.com> wrote:
> On Wed, Dec 9, 2009 at 11:55 AM, Jian Lin <mail@linjian.org> wrote:
>> Full msg in /var/log/messages:
>> Dec =A09 08:38:42 node34 kernel: ------------[ cut here ]-----------=
-
>> Dec =A09 08:38:42 node34 kernel: kernel BUG at fs/btrfs/tree-log.c:2=
661!
>> Dec =A09 08:38:42 node34 kernel: invalid opcode: 0000 [#1] SMP
>> Dec =A09 08:38:42 node34 kernel: last sysfs file:
>> /sys/devices/system/cpu/cpu3/cache/index1/shared_cpu_map
>> Dec =A09 08:38:42 node34 kernel: CPU 0
>> Dec =A09 08:38:42 node34 kernel: Modules linked in: nls_utf8 hfsplus
>> autofs4 i2c_dev i2c_core sunrpc dm_mirror dm_multipath scsi_dh video
>> output sbs sbshc battery acpi_memhotplug ac ipv6 parport_pc lp parpo=
rt
>> joydev ide_cd_mod cdrom serio_raw floppy button tg3 libphy hpilo
>> ata_piix libata e752x_edac rtc_cmos edac_core rtc_core rtc_lib pcspk=
r
>> dm_region_hash dm_log dm_mod shpchp cciss sd_mod scsi_mod ext3 jbd
>> uhci_hcd ohci_hcd ehci_hcd [last unloaded: freq_table]
>> Dec =A09 08:38:42 node34 kernel: Pid: 7354, comm: fstest-mod Not tai=
nted
>> 2.6.32 #1 ProLiant DL380 G4
>> Dec =A09 08:38:42 node34 kernel: RIP: 0010:[<ffffffff81168606>]
>> [<ffffffff81168606>] copy_items+0x2c2/0x2ff
>> Dec =A09 08:38:42 node34 kernel: RSP: 0018:ffff880001fdfcb8 =A0EFLAG=
S: 00010282
>> Dec =A09 08:38:42 node34 kernel: RAX: 00000000ffffffef RBX:
>> ffff88005d494010 RCX: 0000000000000000
>> Dec =A09 08:38:42 node34 kernel: RDX: 0000000000000003 RSI:
>> ffff88007ab10250 RDI: ffff88007e657240
>> Dec =A09 08:38:42 node34 kernel: RBP: ffff88005d494000 R08:
>> ffff880001fdfa28 R09: ffff880001fdfa20
>> Dec =A09 08:38:42 node34 kernel: R10: 000000011b982800 R11:
>> ffff88005a138ce0 R12: 0000000000196000
>> Dec =A09 08:38:42 node34 kernel: R13: ffff88006df62370 R14:
>> ffff88007ab10370 R15: 000000000c302000
>> Dec =A09 08:38:42 node34 kernel: FS: =A000007fccfb4ba6e0(0000)
>> GS:ffff880003c00000(0000) knlGS:0000000000000000
>> Dec =A09 08:38:42 node34 kernel: CS: =A00010 DS: 0000 ES: 0000 CR0: =
000000008005003b
>> Dec =A09 08:38:42 node34 kernel: CR2: 0000000000f58000 CR3:
>> 0000000045fbe000 CR4: 00000000000006f0
>> Dec =A09 08:38:42 node34 kernel: DR0: 0000000000000000 DR1:
>> 0000000000000000 DR2: 0000000000000000
>> Dec =A09 08:38:42 node34 kernel: DR3: 0000000000000000 DR6:
>> 00000000ffff0ff0 DR7: 0000000000000400
>> Dec =A09 08:38:42 node34 kernel: Process fstest-mod (pid: 7354,
>> threadinfo ffff880001fde000, task ffff88007f10c870)
>> Dec =A09 08:38:42 node34 kernel: Stack:
>> Dec =A09 08:38:42 node34 kernel: =A0ffff88007ab102e0 000000330000000=
0
>> ffff88001b982800 ffff88005a138ce0
>> Dec =A09 08:38:42 node34 kernel: <0> ffff8800594e2000 00000033000005=
47
>> 000000034b163000 ffff8800594e242f
>> Dec =A09 08:38:42 node34 kernel: <0> 0000000000000560 00000000000000=
65
>> ffff8800594e20cc 000000338115061d
>> Dec =A09 08:38:42 node34 kernel: Call Trace:
>> Dec =A09 08:38:42 node34 kernel: =A0[<ffffffff81169273>] ?
>> btrfs_log_inode+0x32c/0x467
>> Dec =A09 08:38:42 node34 kernel: =A0[<ffffffff81146000>] ? btrfs_wri=
tepage+0x0/0x4e
>> Dec =A09 08:38:42 node34 kernel: =A0[<ffffffff81169587>] ?
>> btrfs_log_inode_parent+0x1d9/0x2a7
>> Dec =A09 08:38:42 node34 kernel: =A0[<ffffffff8114cc59>] ?
>> btrfs_sync_file+0xd6/0x14d
>> Dec =A09 08:38:42 node34 kernel: =A0[<ffffffff810e4456>] ? vfs_fsync=
_range+0x73/0x9e
>> Dec =A09 08:38:42 node34 kernel: =A0[<ffffffff810e44ff>] ? do_fsync+=
0x27/0x3a
>> Dec =A09 08:38:42 node34 kernel: =A0[<ffffffff810e4530>] ? sys_fsync=
+0xb/0x10
>> Dec =A09 08:38:42 node34 kernel: =A0[<ffffffff8100b8eb>] ?
>> system_call_fastpath+0x16/0x1b
>> Dec =A09 08:38:42 node34 kernel: Code: 24 10 4c 89 f6 e8 5a 16 fc ff=
48
>> 8b 7c 24 20 eb 29 48 8d 6b f0 48 8b 74 24 10 48 8b 7c 24 18 48 89 ea
>> e8 00 4b fd ff 85 c0 74 04 <0f> 0b eb fe 48 89 df e8 c2 a9 05 00 48 =
89
>> ef e8 d2 93 f5 ff 48
>> Dec =A09 08:38:42 node34 kernel: RIP =A0[<ffffffff81168606>] copy_it=
ems+0x2c2/0x2ff
>> Dec =A09 08:38:42 node34 kernel: =A0RSP <ffff880001fdfcb8>
>> Dec =A09 08:38:42 node34 kernel: ---[ end trace 3ea0fce179abe088 ]--=
-
>
> btrfs_csum_file_blocks return -EEXIST, looks like a race.
>
--=20
Jian Lin
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2009-12-09 9:09 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-12-09 1:53 BtrFS does not respond after doing 'fstest' on both original and cloned file Jian Lin
2009-12-09 2:19 ` Yan, Zheng
2009-12-09 3:55 ` Jian Lin
2009-12-09 5:01 ` Yan, Zheng
2009-12-09 9:09 ` Jian Lin
2009-12-09 2:19 ` Zhang Jingwang
2009-12-09 4:11 ` Jian Lin
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.