On Wed, Dec 9, 2009 at 10:19 AM, Zhang Jingwang <yyalone@xxxxxxxxx> wrote: > 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.txt.zip To Zhang: BTW, I am also at ICT, CAS. > > 2009/12/9 Jian Lin <mail@xxxxxxxxxxx>: >> 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 >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in >> the body of a message to majordomo@xxxxxxxxxxxxxxx >> More majordomo info at http://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 > -- Jian Lin -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
