Re: hard freezes with 3.9.0 during io-intensive loads
On Thu, May 16, 2013 at 09:19 (+0200), Kai Krakow wrote: 3.9.2 still does not fix anything. I'll go with autodefrag=off for the moment until I hear some news in that regard. With this new information, is it still helpful to get a metadata image from me? It should be reproducable if you enable autodefrag or defragment cow'ed files. Would still be helpful, yes. If you've got questions on the usage of btrfs-image, your best bet is probably #btrfs on freenode, I haven't created any usable images with that tool so far, but I've heard of people that succeeded. Thanks! -Jan -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: hard freezes with 3.9.0 during io-intensive loads
Jan Schmidt list.bt...@jan-o-sch.net schrieb: Apparently, it's not fixed. The system does not freeze now but it threw multiple backtraces right in front of my Xorg session. The backtraces look a little bit different now. Here's what I got: https://gist.github.com/kakra/8a340f006d01e146865d Occurence while running bedup dedup --defrag --size-cutoff $((1024*1024)) which was currently dedup'ing my backup volume with daily snapshots filled by rsync --inplace - so I suppose some file contents are pretty scattered. At least that looks different for now. I'm not certain about all the fixes in btrfs-next. Can you give it a try and bisect if btrfs-next is good? That would be really helpful. I'd prefer to not bisect my production system kernel... That will probably take ages as running the reproducable test takes about 30-60 minutes before the problem hits my system. At least unless you had a suggestion how to speed up the process... ;-) I see, hoped it would be something quicker. I saw the pull request with those fixes, so I supsect it didn't go into 3.9.1 but rather will go into 3.9.2? Probably. However, those patches obviously weren't enough to solve your problem. We don't submit a lot of things to stable, so they are likely to remain the only btrfs related changes in there, which would mean it is unlikely to help with your problem. I turned off autodefrag which fixes these problems. So without bisect I can at least say the problem is probably somewhere in the new snapshot-aware defragmentation code which came with 3.9.0 or related to the introduction of the same. 3.9.2 still does not fix anything. I'll go with autodefrag=off for the moment until I hear some news in that regard. With this new information, is it still helpful to get a metadata image from me? It should be reproducable if you enable autodefrag or defragment cow'ed files. Regards, Kai -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: hard freezes with 3.9.0 during io-intensive loads
Jan Schmidt list.bt...@jan-o-sch.net schrieb: We can try to debug that further, you can send me / upload the output of btrfs-image -c9 /dev/whatever blah.img built from Josef's repository git://github.com/josefbacik/btrfs-progs.git It contains all your metadata (like file names), data is omitted from the dump. How do I create that image? Is it possible to use it on mounted volumes? If yes, is it possible to write the image to the volume I'm creating the image of? Thanks, Kai -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: hard freezes with 3.9.0 during io-intensive loads
On Fri, May 10, 2013 at 01:30 (+0200), Kai Krakow wrote: Jan Schmidt list.bt...@jan-o-sch.net schrieb: Apparently, it's not fixed. The system does not freeze now but it threw multiple backtraces right in front of my Xorg session. The backtraces look a little bit different now. Here's what I got: https://gist.github.com/kakra/8a340f006d01e146865d Occurence while running bedup dedup --defrag --size-cutoff $((1024*1024)) which was currently dedup'ing my backup volume with daily snapshots filled by rsync --inplace - so I suppose some file contents are pretty scattered. At least that looks different for now. I'm not certain about all the fixes in btrfs-next. Can you give it a try and bisect if btrfs-next is good? That would be really helpful. I'd prefer to not bisect my production system kernel... That will probably take ages as running the reproducable test takes about 30-60 minutes before the problem hits my system. At least unless you had a suggestion how to speed up the process... ;-) I see, hoped it would be something quicker. I saw the pull request with those fixes, so I supsect it didn't go into 3.9.1 but rather will go into 3.9.2? Probably. However, those patches obviously weren't enough to solve your problem. We don't submit a lot of things to stable, so they are likely to remain the only btrfs related changes in there, which would mean it is unlikely to help with your problem. We can try to debug that further, you can send me / upload the output of btrfs-image -c9 /dev/whatever blah.img built from Josef's repository git://github.com/josefbacik/btrfs-progs.git It contains all your metadata (like file names), data is omitted from the dump. I probably wait and just do not run the dedup process until I have 3.9.2 installed. The backup works with occassional hiccups, the system very very sometimes freezes but I almost always see the backtraces in dmesg after backup. Let's see if it's all gone in 3.9.2. It's always an alternative to hope for the best :-) -Jan -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: hard freezes with 3.9.0 during io-intensive loads
On Wed, May 08, 2013 at 02:24 (+0200), Kai Krakow wrote: Kai Krakow hurikhan77+bt...@gmail.com schrieb: I can reliably reproduce it from two different approaches. I'd like to only apply the commits fixing it. Can you name them here? In git log order: 6ced2666 Btrfs: separate sequence numbers for delayed ref tracking and tree mod log ef9120b1 Btrfs: fix tree mod log regression on root split operations 2ed098ca Btrfs: fix accessing the root pointer in tree mod log functions 50723551 Btrfs: fix unlock after free on rewinded tree blocks The commit ids are from josef's master branch (git://git.kernel.org/pub/scm/linux/kernel/git/josef/btrfs-next.git) which is known not to be very stable regarding commit ids. Thanks, applied almost cleanly to 3.9.0 vanilla with just one reject. And that was for some error message. I'm simply ignoring that and currently compiling it. I will get back here with the result (fixed or not fixed for one or both situations). Apparently, it's not fixed. The system does not freeze now but it threw multiple backtraces right in front of my Xorg session. The backtraces look a little bit different now. Here's what I got: https://gist.github.com/kakra/8a340f006d01e146865d Occurence while running bedup dedup --defrag --size-cutoff $((1024*1024)) which was currently dedup'ing my backup volume with daily snapshots filled by rsync --inplace - so I suppose some file contents are pretty scattered. At least that looks different for now. I'm not certain about all the fixes in btrfs-next. Can you give it a try and bisect if btrfs-next is good? That would be really helpful. -Jan [ 2612.573501] [ cut here ] [ 2612.573509] WARNING: at fs/btrfs/inode.c:2157 record_one_backref+0x310/0x328() [ 2612.573510] Hardware name: To Be Filled By O.E.M. [ 2612.573511] Modules linked in: rfcomm bnep af_packet vsock(O) vmmon(O) vmnet(O) vmci(O) vmblock(O) reiserfs snd_usb_audio snd_usbmidi_lib snd_rawmidi snd_seq_device gspca_sonixj gspca_main videodev gpio_ich coretemp hwmon kvm_intel kvm crc32_pclmul crc32c_intel btusb microcode bluetooth pcspkr lpc_ich i2c_i801 8250 mfd_core serial_core evdev usb_storage zram(C) unix [ 2612.573528] Pid: 13112, comm: btrfs-endio-wri Tainted: G C O 3.9.0-gentoo #3 [ 2612.573529] Call Trace: [ 2612.573534] [8102f11d] ? warn_slowpath_common+0x78/0x8e [ 2612.573536] [81183aed] ? record_one_backref+0x310/0x328 [ 2612.573540] [811c5eb0] ? iterate_extent_inodes+0x177/0x23c [ 2612.573542] [811837dd] ? btrfs_real_readdir+0x482/0x482 [ 2612.573543] [811837dd] ? btrfs_real_readdir+0x482/0x482 [ 2612.573545] [811c5ffe] ? iterate_inodes_from_logical+0x89/0x96 [ 2612.573547] [81182320] ? record_extent_backrefs+0x4d/0x8e [ 2612.573549] [8118a8d3] ? btrfs_finish_ordered_io+0x671/0x798 [ 2612.573552] [811a33f3] ? worker_loop+0x176/0x493 [ 2612.573553] [811a327d] ? btrfs_queue_worker+0x272/0x272 [ 2612.573554] [811a327d] ? btrfs_queue_worker+0x272/0x272 [ 2612.573557] [810496d2] ? kthread+0x81/0x89 [ 2612.573560] [8105] ? free_sched_groups+0x32/0x50 [ 2612.573561] [81049651] ? kthread_freezable_should_stop+0x36/0x36 [ 2612.573564] [8151c6ac] ? ret_from_fork+0x7c/0xb0 [ 2612.573566] [81049651] ? kthread_freezable_should_stop+0x36/0x36 [ 2612.573567] ---[ end trace 4c42d11ebaf277b6 ]--- [ 2612.574001] [ cut here ] [ 2612.574004] WARNING: at fs/btrfs/inode.c:2157 record_one_backref+0x310/0x328() [ 2612.574004] Hardware name: To Be Filled By O.E.M. [ 2612.574005] Modules linked in: rfcomm bnep af_packet vsock(O) vmmon(O) vmnet(O) vmci(O) vmblock(O) reiserfs snd_usb_audio snd_usbmidi_lib snd_rawmidi snd_seq_device gspca_sonixj gspca_main videodev gpio_ich coretemp hwmon kvm_intel kvm crc32_pclmul crc32c_intel btusb microcode bluetooth pcspkr lpc_ich i2c_i801 8250 mfd_core serial_core evdev usb_storage zram(C) unix [ 2612.574017] Pid: 13110, comm: btrfs-endio-wri Tainted: GWC O 3.9.0-gentoo #3 [ 2612.574018] Call Trace: [ 2612.574020] [8102f11d] ? warn_slowpath_common+0x78/0x8e [ 2612.574021] [81183aed] ? record_one_backref+0x310/0x328 [ 2612.574023] [811c5eb0] ? iterate_extent_inodes+0x177/0x23c [ 2612.574025] [811837dd] ? btrfs_real_readdir+0x482/0x482 [ 2612.574027] [811837dd] ? btrfs_real_readdir+0x482/0x482 [ 2612.574029] [811c5ffe] ? iterate_inodes_from_logical+0x89/0x96 [ 2612.574030] [81182320] ? record_extent_backrefs+0x4d/0x8e [ 2612.574032] [8118a8d3] ? btrfs_finish_ordered_io+0x671/0x798 [ 2612.574034] [811a33f3] ? worker_loop+0x176/0x493 [ 2612.574035] [811a327d] ? btrfs_queue_worker+0x272/0x272 [ 2612.574036] [811a327d] ? btrfs_queue_worker+0x272/0x272 [ 2612.574038]
Re: hard freezes with 3.9.0 during io-intensive loads
On Mon, May 06, 2013 at 22:29 (+0200), Kai Krakow wrote: Jan Schmidt list.bt...@jan-o-sch.net schrieb: That one should be fixed in btrfs-next. If you can reliably reproduce the bug I'd be glad to get a confirmation - you can probably even save putting it on bugzilla then ;-) I can reliably reproduce it from two different approaches. I'd like to only apply the commits fixing it. Can you name them here? In git log order: 6ced2666 Btrfs: separate sequence numbers for delayed ref tracking and tree mod log ef9120b1 Btrfs: fix tree mod log regression on root split operations 2ed098ca Btrfs: fix accessing the root pointer in tree mod log functions 50723551 Btrfs: fix unlock after free on rewinded tree blocks The commit ids are from josef's master branch (git://git.kernel.org/pub/scm/linux/kernel/git/josef/btrfs-next.git) which is known not to be very stable regarding commit ids. Thanks, -Jan [snip] -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: hard freezes with 3.9.0 during io-intensive loads
Jan Schmidt list.bt...@jan-o-sch.net schrieb: I can reliably reproduce it from two different approaches. I'd like to only apply the commits fixing it. Can you name them here? In git log order: 6ced2666 Btrfs: separate sequence numbers for delayed ref tracking and tree mod log ef9120b1 Btrfs: fix tree mod log regression on root split operations 2ed098ca Btrfs: fix accessing the root pointer in tree mod log functions 50723551 Btrfs: fix unlock after free on rewinded tree blocks The commit ids are from josef's master branch (git://git.kernel.org/pub/scm/linux/kernel/git/josef/btrfs-next.git) which is known not to be very stable regarding commit ids. Thanks, applied almost cleanly to 3.9.0 vanilla with just one reject. And that was for some error message. I'm simply ignoring that and currently compiling it. I will get back here with the result (fixed or not fixed for one or both situations). Regards, Kai -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: hard freezes with 3.9.0 during io-intensive loads
Kai Krakow hurikhan77+bt...@gmail.com schrieb: I can reliably reproduce it from two different approaches. I'd like to only apply the commits fixing it. Can you name them here? In git log order: 6ced2666 Btrfs: separate sequence numbers for delayed ref tracking and tree mod log ef9120b1 Btrfs: fix tree mod log regression on root split operations 2ed098ca Btrfs: fix accessing the root pointer in tree mod log functions 50723551 Btrfs: fix unlock after free on rewinded tree blocks The commit ids are from josef's master branch (git://git.kernel.org/pub/scm/linux/kernel/git/josef/btrfs-next.git) which is known not to be very stable regarding commit ids. Thanks, applied almost cleanly to 3.9.0 vanilla with just one reject. And that was for some error message. I'm simply ignoring that and currently compiling it. I will get back here with the result (fixed or not fixed for one or both situations). Apparently, it's not fixed. The system does not freeze now but it threw multiple backtraces right in front of my Xorg session. The backtraces look a little bit different now. Here's what I got: https://gist.github.com/kakra/8a340f006d01e146865d Occurence while running bedup dedup --defrag --size-cutoff $((1024*1024)) which was currently dedup'ing my backup volume with daily snapshots filled by rsync --inplace - so I suppose some file contents are pretty scattered. [ 2612.573501] [ cut here ] [ 2612.573509] WARNING: at fs/btrfs/inode.c:2157 record_one_backref+0x310/0x328() [ 2612.573510] Hardware name: To Be Filled By O.E.M. [ 2612.573511] Modules linked in: rfcomm bnep af_packet vsock(O) vmmon(O) vmnet(O) vmci(O) vmblock(O) reiserfs snd_usb_audio snd_usbmidi_lib snd_rawmidi snd_seq_device gspca_sonixj gspca_main videodev gpio_ich coretemp hwmon kvm_intel kvm crc32_pclmul crc32c_intel btusb microcode bluetooth pcspkr lpc_ich i2c_i801 8250 mfd_core serial_core evdev usb_storage zram(C) unix [ 2612.573528] Pid: 13112, comm: btrfs-endio-wri Tainted: G C O 3.9.0-gentoo #3 [ 2612.573529] Call Trace: [ 2612.573534] [8102f11d] ? warn_slowpath_common+0x78/0x8e [ 2612.573536] [81183aed] ? record_one_backref+0x310/0x328 [ 2612.573540] [811c5eb0] ? iterate_extent_inodes+0x177/0x23c [ 2612.573542] [811837dd] ? btrfs_real_readdir+0x482/0x482 [ 2612.573543] [811837dd] ? btrfs_real_readdir+0x482/0x482 [ 2612.573545] [811c5ffe] ? iterate_inodes_from_logical+0x89/0x96 [ 2612.573547] [81182320] ? record_extent_backrefs+0x4d/0x8e [ 2612.573549] [8118a8d3] ? btrfs_finish_ordered_io+0x671/0x798 [ 2612.573552] [811a33f3] ? worker_loop+0x176/0x493 [ 2612.573553] [811a327d] ? btrfs_queue_worker+0x272/0x272 [ 2612.573554] [811a327d] ? btrfs_queue_worker+0x272/0x272 [ 2612.573557] [810496d2] ? kthread+0x81/0x89 [ 2612.573560] [8105] ? free_sched_groups+0x32/0x50 [ 2612.573561] [81049651] ? kthread_freezable_should_stop+0x36/0x36 [ 2612.573564] [8151c6ac] ? ret_from_fork+0x7c/0xb0 [ 2612.573566] [81049651] ? kthread_freezable_should_stop+0x36/0x36 [ 2612.573567] ---[ end trace 4c42d11ebaf277b6 ]--- [ 2612.574001] [ cut here ] [ 2612.574004] WARNING: at fs/btrfs/inode.c:2157 record_one_backref+0x310/0x328() [ 2612.574004] Hardware name: To Be Filled By O.E.M. [ 2612.574005] Modules linked in: rfcomm bnep af_packet vsock(O) vmmon(O) vmnet(O) vmci(O) vmblock(O) reiserfs snd_usb_audio snd_usbmidi_lib snd_rawmidi snd_seq_device gspca_sonixj gspca_main videodev gpio_ich coretemp hwmon kvm_intel kvm crc32_pclmul crc32c_intel btusb microcode bluetooth pcspkr lpc_ich i2c_i801 8250 mfd_core serial_core evdev usb_storage zram(C) unix [ 2612.574017] Pid: 13110, comm: btrfs-endio-wri Tainted: GWC O 3.9.0-gentoo #3 [ 2612.574018] Call Trace: [ 2612.574020] [8102f11d] ? warn_slowpath_common+0x78/0x8e [ 2612.574021] [81183aed] ? record_one_backref+0x310/0x328 [ 2612.574023] [811c5eb0] ? iterate_extent_inodes+0x177/0x23c [ 2612.574025] [811837dd] ? btrfs_real_readdir+0x482/0x482 [ 2612.574027] [811837dd] ? btrfs_real_readdir+0x482/0x482 [ 2612.574029] [811c5ffe] ? iterate_inodes_from_logical+0x89/0x96 [ 2612.574030] [81182320] ? record_extent_backrefs+0x4d/0x8e [ 2612.574032] [8118a8d3] ? btrfs_finish_ordered_io+0x671/0x798 [ 2612.574034] [811a33f3] ? worker_loop+0x176/0x493 [ 2612.574035] [811a327d] ? btrfs_queue_worker+0x272/0x272 [ 2612.574036] [811a327d] ? btrfs_queue_worker+0x272/0x272 [ 2612.574038] [810496d2] ? kthread+0x81/0x89 [ 2612.574040] [8105] ? free_sched_groups+0x32/0x50 [ 2612.574041] [81049651] ? kthread_freezable_should_stop+0x36/0x36 [ 2612.574043] [8151c6ac] ? ret_from_fork+0x7c/0xb0 [ 2612.574045] [81049651] ?
Re: hard freezes with 3.9.0 during io-intensive loads
Josef Bacik jba...@fusionio.com schrieb: I've upgraded to 3.9.0 mainly for the snapshot-aware defragging patches. I'm running bedup[1] on a regular basis and it is now the third time that I got back to my PC just to find it hard-frozen and I needed to use the reset button. It looks like this happens only while running bedup on my two btrfs filesystems but I'm not sure if it happens for any of the filesystems or only one. This is my setup: [snip] Can you please file a bug for this issue on bugzilla.kernel.org so I can make sure we don't lose track of it? Make sure the component is set to Btrfs. Meanwhile I found out: It does not only happen during dedup with bedup but also when creating my rsync backup. I will file all the details to bugzilla this evening. Thanks, Kai -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: hard freezes with 3.9.0 during io-intensive loads
On Sun, May 05, 2013 at 18:10 (+0200), Kai Krakow wrote:
Hello list,
Kai Krakow hurikhan77+bt...@gmail.com schrieb:
I've upgraded to 3.9.0 mainly for the snapshot-aware defragging patches.
I'm running bedup[1] on a regular basis and it is now the third time that
I got back to my PC just to find it hard-frozen and I needed to use the
reset button.
It looks like this happens only while running bedup on my two btrfs
filesystems but I'm not sure if it happens for any of the filesystems or
only one. This is my setup:
# cat /etc/fstab (shortened)
UUID=d2bb232a-2e8f-4951-8bcc-97e237f1b536 / btrfs
compress=lzo,subvol=root64 0 1 # /dev/sd{a,b,c}3
LABEL=usb-backup /mnt/private/usb-backup btrfs noauto,compress-
force=zlib,subvolid=0,autodefrag,comment=systemd.automount 0 0 # external
usb3 disk
# btrfs filesystem show
Label: 'usb-backup' uuid: 7038c8fa-4293-49e9-b493-a9c46e5663ca
Total devices 1 FS bytes used 1.13TB
devid1 size 1.82TB used 1.75TB path /dev/sdd1
Label: 'system' uuid: d2bb232a-2e8f-4951-8bcc-97e237f1b536
Total devices 3 FS bytes used 914.43GB
devid3 size 927.26GB used 426.03GB path /dev/sdc3
devid2 size 927.26GB used 426.03GB path /dev/sdb3
devid1 size 927.26GB used 427.07GB path /dev/sda3
Btrfs v0.20-rc1
Since the system hard-freezes I have no messages from dmesg. But I suspect
it to be related to the defragmentation option in bedup (I've switched to
bedub with --defrag since 3.9.0, and autodefrag for the backup drive).
Just in case, I'm going to try without this option now and see if it won't
freeze.
I was able to take a physical screenshot with a real camera of a kernel
backtrace one time when the freeze happened. I wonder if it is useful to
you and where to send it. I just don't want to upload jpegs right here to
the list without asking first.
The big plus is: Altough I had to hard-reset the frozen system several
times now, btrfs survived the procedure without any impact (just boot
times increases noticeably, probably due to log-replays or something). So
thumbs up for the developers on that point.
Thanks to the great cwillu netcat service here's my backtrace:
That one should be fixed in btrfs-next. If you can reliably reproduce the bug
I'd be glad to get a confirmation - you can probably even save putting it on
bugzilla then ;-)
-Jan
4,1072,17508258745,-;[ cut here ]
2,1073,17508258772,-;kernel BUG at fs/btrfs/ctree.c:1144!
4,1074,17508258791,-;invalid opcode: [#1] SMP
4,1075,17508258811,-;Modules linked in: bnep bluetooth af_packet vmci(O)
vmmon(O) vmblock(O) vmnet(O) vsock reiserfs snd_usb_audio snd_usbmidi_lib
snd_rawmidi snd_seq_device gspca_sonixj gpio_ich gspca_main videodev
coretemp hwmon kvm_intel kvm crc32_pclmul crc32c_intel 8250 serial_core
lpc_ich microcode mfd_core i2c_i801 pcspkr evdev usb_storage zram(C) unix
4,1076,17508258966,-;CPU 0
4,1077,17508258977,-;Pid: 7212, comm: btrfs-endio-wri Tainted: G C O
3.9.0-gentoo #2 To Be Filled By O.E.M. To Be Filled By O.E.M./Z68 Pro3
4,1078,17508259023,-;RIP: 0010:[81161d12] [81161d12]
__tree_mod_log_rewind+0x4c/0x121
4,1079,17508259064,-;RSP: 0018:8801966718e8 EFLAGS: 00010293
4,1080,17508259085,-;RAX: 0003 RBX: 8801ee8d33b0 RCX:
880196671888
4,1081,17508259112,-;RDX: 0a4596a4 RSI: 0eee RDI:
8804087be700
4,1082,17508259138,-;RBP: 0071 R08: 1000 R09:
880196671898
4,1083,17508259165,-;R10: R11: R12:
880406c2e000
4,1084,17508259191,-;R13: 8a11 R14: 8803b5aa1200 R15:
0001
4,1085,17508259218,-;FS: () GS:88041f20()
knlGS:
4,1086,17508259248,-;CS: 0010 DS: ES: CR0: 80050033
4,1087,17508259270,-;CR2: 026f0390 CR3: 01a0b000 CR4:
000407f0
4,1088,17508259297,-;DR0: DR1: DR2:
4,1089,17508259323,-;DR3: DR6: 0ff0 DR7:
0400
4,1090,17508259350,-;Process btrfs-endio-wri (pid: 7212, threadinfo
88019667, task 8801b82e5400)
4,1091,17508259383,-;Stack:
4,1092,17508259391,-; 8801ee8d38f0 880021b6f360 88013a5b2000
8a11
4,1093,17508259423,-; 8802d0a14000 81167606 0246
8801ee8d33b0
4,1094,17508259455,-; 880406c2e000 8801966719bf 880021b6f360
4,1095,17508259488,-;Call Trace:
4,1096,17508259500,-; [81167606] ?
btrfs_search_old_slot+0x543/0x61e
4,1097,17508259526,-; [811692de] ? btrfs_next_old_leaf+0x8a/0x332
4,1098,17508259552,-; [811c484a] ?
__resolve_indirect_refs+0x2d8/0x408
4,1099,17508259578,-; [811c533b] ? find_parent_nodes+0x9c1/0xcec
4,1100,17508259602,-; [811c5e06]
Re: hard freezes with 3.9.0 during io-intensive loads
I have this problem too, and I cannot reproduce it properly... When is
that patch in btrfs-next going to be in the mainline kernel?
On Mon, May 6, 2013 at 10:55 AM, Jan Schmidt list.bt...@jan-o-sch.net wrote:
On Sun, May 05, 2013 at 18:10 (+0200), Kai Krakow wrote:
Hello list,
Kai Krakow hurikhan77+bt...@gmail.com schrieb:
I've upgraded to 3.9.0 mainly for the snapshot-aware defragging patches.
I'm running bedup[1] on a regular basis and it is now the third time that
I got back to my PC just to find it hard-frozen and I needed to use the
reset button.
It looks like this happens only while running bedup on my two btrfs
filesystems but I'm not sure if it happens for any of the filesystems or
only one. This is my setup:
# cat /etc/fstab (shortened)
UUID=d2bb232a-2e8f-4951-8bcc-97e237f1b536 / btrfs
compress=lzo,subvol=root64 0 1 # /dev/sd{a,b,c}3
LABEL=usb-backup /mnt/private/usb-backup btrfs noauto,compress-
force=zlib,subvolid=0,autodefrag,comment=systemd.automount 0 0 # external
usb3 disk
# btrfs filesystem show
Label: 'usb-backup' uuid: 7038c8fa-4293-49e9-b493-a9c46e5663ca
Total devices 1 FS bytes used 1.13TB
devid1 size 1.82TB used 1.75TB path /dev/sdd1
Label: 'system' uuid: d2bb232a-2e8f-4951-8bcc-97e237f1b536
Total devices 3 FS bytes used 914.43GB
devid3 size 927.26GB used 426.03GB path /dev/sdc3
devid2 size 927.26GB used 426.03GB path /dev/sdb3
devid1 size 927.26GB used 427.07GB path /dev/sda3
Btrfs v0.20-rc1
Since the system hard-freezes I have no messages from dmesg. But I suspect
it to be related to the defragmentation option in bedup (I've switched to
bedub with --defrag since 3.9.0, and autodefrag for the backup drive).
Just in case, I'm going to try without this option now and see if it won't
freeze.
I was able to take a physical screenshot with a real camera of a kernel
backtrace one time when the freeze happened. I wonder if it is useful to
you and where to send it. I just don't want to upload jpegs right here to
the list without asking first.
The big plus is: Altough I had to hard-reset the frozen system several
times now, btrfs survived the procedure without any impact (just boot
times increases noticeably, probably due to log-replays or something). So
thumbs up for the developers on that point.
Thanks to the great cwillu netcat service here's my backtrace:
That one should be fixed in btrfs-next. If you can reliably reproduce the bug
I'd be glad to get a confirmation - you can probably even save putting it on
bugzilla then ;-)
-Jan
4,1072,17508258745,-;[ cut here ]
2,1073,17508258772,-;kernel BUG at fs/btrfs/ctree.c:1144!
4,1074,17508258791,-;invalid opcode: [#1] SMP
4,1075,17508258811,-;Modules linked in: bnep bluetooth af_packet vmci(O)
vmmon(O) vmblock(O) vmnet(O) vsock reiserfs snd_usb_audio snd_usbmidi_lib
snd_rawmidi snd_seq_device gspca_sonixj gpio_ich gspca_main videodev
coretemp hwmon kvm_intel kvm crc32_pclmul crc32c_intel 8250 serial_core
lpc_ich microcode mfd_core i2c_i801 pcspkr evdev usb_storage zram(C) unix
4,1076,17508258966,-;CPU 0
4,1077,17508258977,-;Pid: 7212, comm: btrfs-endio-wri Tainted: G C O
3.9.0-gentoo #2 To Be Filled By O.E.M. To Be Filled By O.E.M./Z68 Pro3
4,1078,17508259023,-;RIP: 0010:[81161d12] [81161d12]
__tree_mod_log_rewind+0x4c/0x121
4,1079,17508259064,-;RSP: 0018:8801966718e8 EFLAGS: 00010293
4,1080,17508259085,-;RAX: 0003 RBX: 8801ee8d33b0 RCX:
880196671888
4,1081,17508259112,-;RDX: 0a4596a4 RSI: 0eee RDI:
8804087be700
4,1082,17508259138,-;RBP: 0071 R08: 1000 R09:
880196671898
4,1083,17508259165,-;R10: R11: R12:
880406c2e000
4,1084,17508259191,-;R13: 8a11 R14: 8803b5aa1200 R15:
0001
4,1085,17508259218,-;FS: () GS:88041f20()
knlGS:
4,1086,17508259248,-;CS: 0010 DS: ES: CR0: 80050033
4,1087,17508259270,-;CR2: 026f0390 CR3: 01a0b000 CR4:
000407f0
4,1088,17508259297,-;DR0: DR1: DR2:
4,1089,17508259323,-;DR3: DR6: 0ff0 DR7:
0400
4,1090,17508259350,-;Process btrfs-endio-wri (pid: 7212, threadinfo
88019667, task 8801b82e5400)
4,1091,17508259383,-;Stack:
4,1092,17508259391,-; 8801ee8d38f0 880021b6f360 88013a5b2000
8a11
4,1093,17508259423,-; 8802d0a14000 81167606 0246
8801ee8d33b0
4,1094,17508259455,-; 880406c2e000 8801966719bf 880021b6f360
4,1095,17508259488,-;Call Trace:
4,1096,17508259500,-; [81167606] ?
btrfs_search_old_slot+0x543/0x61e
4,1097,17508259526,-; [811692de] ? btrfs_next_old_leaf+0x8a/0x332
Re: hard freezes with 3.9.0 during io-intensive loads
Jan Schmidt list.bt...@jan-o-sch.net schrieb: That one should be fixed in btrfs-next. If you can reliably reproduce the bug I'd be glad to get a confirmation - you can probably even save putting it on bugzilla then ;-) I can reliably reproduce it from two different approaches. I'd like to only apply the commits fixing it. Can you name them here? 4,1072,17508258745,-;[ cut here ] 2,1073,17508258772,-;kernel BUG at fs/btrfs/ctree.c:1144! 4,1074,17508258791,-;invalid opcode: [#1] SMP 4,1075,17508258811,-;Modules linked in: bnep bluetooth af_packet vmci(O) vmmon(O) vmblock(O) vmnet(O) vsock reiserfs snd_usb_audio snd_usbmidi_lib snd_rawmidi snd_seq_device gspca_sonixj gpio_ich gspca_main videodev coretemp hwmon kvm_intel kvm crc32_pclmul crc32c_intel 8250 serial_core lpc_ich microcode mfd_core i2c_i801 pcspkr evdev usb_storage zram(C) unix 4,1076,17508258966,-;CPU 0 4,1077,17508258977,-;Pid: 7212, comm: btrfs-endio-wri Tainted: G C O 3.9.0-gentoo #2 To Be Filled By O.E.M. To Be Filled By O.E.M./Z68 Pro3 4,1078,17508259023,-;RIP: 0010:[81161d12] [81161d12] __tree_mod_log_rewind+0x4c/0x121 4,1079,17508259064,-;RSP: 0018:8801966718e8 EFLAGS: 00010293 4,1080,17508259085,-;RAX: 0003 RBX: 8801ee8d33b0 RCX: 880196671888 4,1081,17508259112,-;RDX: 0a4596a4 RSI: 0eee RDI: 8804087be700 4,1082,17508259138,-;RBP: 0071 R08: 1000 R09: 880196671898 4,1083,17508259165,-;R10: R11: R12: 880406c2e000 4,1084,17508259191,-;R13: 8a11 R14: 8803b5aa1200 R15: 0001 4,1085,17508259218,-;FS: () GS:88041f20() knlGS: 4,1086,17508259248,-;CS: 0010 DS: ES: CR0: 80050033 4,1087,17508259270,-;CR2: 026f0390 CR3: 01a0b000 CR4: 000407f0 4,1088,17508259297,-;DR0: DR1: DR2: 4,1089,17508259323,-;DR3: DR6: 0ff0 DR7: 0400 4,1090,17508259350,-;Process btrfs-endio-wri (pid: 7212, threadinfo 88019667, task 8801b82e5400) 4,1091,17508259383,-;Stack: 4,1092,17508259391,-; 8801ee8d38f0 880021b6f360 88013a5b2000 8a11 4,1093,17508259423,-; 8802d0a14000 81167606 0246 8801ee8d33b0 4,1094,17508259455,-; 880406c2e000 8801966719bf 880021b6f360 4,1095,17508259488,-;Call Trace: 4,1096,17508259500,-; [81167606] ? btrfs_search_old_slot+0x543/0x61e 4,1097,17508259526,-; [811692de] ? btrfs_next_old_leaf+0x8a/0x332 4,1098,17508259552,-; [811c484a] ? __resolve_indirect_refs+0x2d8/0x408 4,1099,17508259578,-; [811c533b] ? find_parent_nodes+0x9c1/0xcec 4,1100,17508259602,-; [811c5e06] ? iterate_extent_inodes+0xf1/0x23c 4,1101,17508259628,-; [811837b9] ? btrfs_real_readdir+0x482/0x482 4,1102,17508259652,-; [81194db7] ? release_extent_buffer.isra.19+0x27/0x88 4,1103,17508259679,-; [811837b9] ? btrfs_real_readdir+0x482/0x482 4,1104,17508259703,-; [811c5fda] ? iterate_inodes_from_logical+0x89/0x96 4,1105,17508259729,-; [811822fc] ? record_extent_backrefs+0x4d/0x8e 4,1106,17508259755,-; [8118a8af] ? btrfs_finish_ordered_io+0x671/0x798 4,1107,17508259781,-; [811a33cf] ? worker_loop+0x176/0x493 4,1108,17508259803,-; [811a3259] ? btrfs_queue_worker+0x272/0x272 4,1109,17508259827,-; [811a3259] ? btrfs_queue_worker+0x272/0x272 4,1110,17508259852,-; [810496d2] ? kthread+0x81/0x89 4,,17508259873,-; [8105] ? free_sched_groups+0x32/0x50 4,1112,17508259896,-; [81049651] ? kthread_freezable_should_stop+0x36/0x36 4,1113,17508259924,-; [8151c66c] ? ret_from_fork+0x7c/0xb0 4,1114,17508259947,-; [81049651] ? kthread_freezable_should_stop+0x36/0x36 4,1115,17508259974,-;Code: 85 e4 89 c5 0f 85 d6 00 00 00 e9 db 00 00 00 41 83 7e 28 05 0f 87 ab 00 00 00 41 8b 46 28 ff 24 c5 20 78 62 81 41 39 6e 2c 73 02 0f 0b 41 8b 56 2c 49 8d 76 38 48 89 df ff c5 e8 7c fb ff ff 49 1,1116,17508260117,-;RIP [81161d12] __tree_mod_log_rewind+0x4c/0x121 4,1117,17508260144,-; RSP 8801966718e8 4,1118,17508446926,-;---[ end trace e7a8cddfc052e9e9 ]--- -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
hard freezes with 3.9.0 during io-intensive loads
Hello list,
I've upgraded to 3.9.0 mainly for the snapshot-aware defragging patches. I'm
running bedup[1] on a regular basis and it is now the third time that I got
back to my PC just to find it hard-frozen and I needed to use the reset
button.
It looks like this happens only while running bedup on my two btrfs
filesystems but I'm not sure if it happens for any of the filesystems or
only one. This is my setup:
# cat /etc/fstab (shortened)
UUID=d2bb232a-2e8f-4951-8bcc-97e237f1b536 / btrfs compress=lzo,subvol=root64
0 1 # /dev/sd{a,b,c}3
LABEL=usb-backup /mnt/private/usb-backup btrfs noauto,compress-
force=zlib,subvolid=0,autodefrag,comment=systemd.automount 0 0 # external
usb3 disk
# btrfs filesystem show
Label: 'usb-backup' uuid: 7038c8fa-4293-49e9-b493-a9c46e5663ca
Total devices 1 FS bytes used 1.13TB
devid1 size 1.82TB used 1.75TB path /dev/sdd1
Label: 'system' uuid: d2bb232a-2e8f-4951-8bcc-97e237f1b536
Total devices 3 FS bytes used 914.43GB
devid3 size 927.26GB used 426.03GB path /dev/sdc3
devid2 size 927.26GB used 426.03GB path /dev/sdb3
devid1 size 927.26GB used 427.07GB path /dev/sda3
Btrfs v0.20-rc1
Since the system hard-freezes I have no messages from dmesg. But I suspect
it to be related to the defragmentation option in bedup (I've switched to
bedub with --defrag since 3.9.0, and autodefrag for the backup drive). Just
in case, I'm going to try without this option now and see if it won't
freeze.
I was able to take a physical screenshot with a real camera of a kernel
backtrace one time when the freeze happened. I wonder if it is useful to you
and where to send it. I just don't want to upload jpegs right here to the
list without asking first.
The big plus is: Altough I had to hard-reset the frozen system several times
now, btrfs survived the procedure without any impact (just boot times
increases noticeably, probably due to log-replays or something). So thumbs
up for the developers on that point.
[1]: https://github.com/g2p/bedup
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: hard freezes with 3.9.0 during io-intensive loads
Hello list,
Kai Krakow hurikhan77+bt...@gmail.com schrieb:
I've upgraded to 3.9.0 mainly for the snapshot-aware defragging patches.
I'm running bedup[1] on a regular basis and it is now the third time that
I got back to my PC just to find it hard-frozen and I needed to use the
reset button.
It looks like this happens only while running bedup on my two btrfs
filesystems but I'm not sure if it happens for any of the filesystems or
only one. This is my setup:
# cat /etc/fstab (shortened)
UUID=d2bb232a-2e8f-4951-8bcc-97e237f1b536 / btrfs
compress=lzo,subvol=root64 0 1 # /dev/sd{a,b,c}3
LABEL=usb-backup /mnt/private/usb-backup btrfs noauto,compress-
force=zlib,subvolid=0,autodefrag,comment=systemd.automount 0 0 # external
usb3 disk
# btrfs filesystem show
Label: 'usb-backup' uuid: 7038c8fa-4293-49e9-b493-a9c46e5663ca
Total devices 1 FS bytes used 1.13TB
devid1 size 1.82TB used 1.75TB path /dev/sdd1
Label: 'system' uuid: d2bb232a-2e8f-4951-8bcc-97e237f1b536
Total devices 3 FS bytes used 914.43GB
devid3 size 927.26GB used 426.03GB path /dev/sdc3
devid2 size 927.26GB used 426.03GB path /dev/sdb3
devid1 size 927.26GB used 427.07GB path /dev/sda3
Btrfs v0.20-rc1
Since the system hard-freezes I have no messages from dmesg. But I suspect
it to be related to the defragmentation option in bedup (I've switched to
bedub with --defrag since 3.9.0, and autodefrag for the backup drive).
Just in case, I'm going to try without this option now and see if it won't
freeze.
I was able to take a physical screenshot with a real camera of a kernel
backtrace one time when the freeze happened. I wonder if it is useful to
you and where to send it. I just don't want to upload jpegs right here to
the list without asking first.
The big plus is: Altough I had to hard-reset the frozen system several
times now, btrfs survived the procedure without any impact (just boot
times increases noticeably, probably due to log-replays or something). So
thumbs up for the developers on that point.
Thanks to the great cwillu netcat service here's my backtrace:
4,1072,17508258745,-;[ cut here ]
2,1073,17508258772,-;kernel BUG at fs/btrfs/ctree.c:1144!
4,1074,17508258791,-;invalid opcode: [#1] SMP
4,1075,17508258811,-;Modules linked in: bnep bluetooth af_packet vmci(O)
vmmon(O) vmblock(O) vmnet(O) vsock reiserfs snd_usb_audio snd_usbmidi_lib
snd_rawmidi snd_seq_device gspca_sonixj gpio_ich gspca_main videodev
coretemp hwmon kvm_intel kvm crc32_pclmul crc32c_intel 8250 serial_core
lpc_ich microcode mfd_core i2c_i801 pcspkr evdev usb_storage zram(C) unix
4,1076,17508258966,-;CPU 0
4,1077,17508258977,-;Pid: 7212, comm: btrfs-endio-wri Tainted: G C O
3.9.0-gentoo #2 To Be Filled By O.E.M. To Be Filled By O.E.M./Z68 Pro3
4,1078,17508259023,-;RIP: 0010:[81161d12] [81161d12]
__tree_mod_log_rewind+0x4c/0x121
4,1079,17508259064,-;RSP: 0018:8801966718e8 EFLAGS: 00010293
4,1080,17508259085,-;RAX: 0003 RBX: 8801ee8d33b0 RCX:
880196671888
4,1081,17508259112,-;RDX: 0a4596a4 RSI: 0eee RDI:
8804087be700
4,1082,17508259138,-;RBP: 0071 R08: 1000 R09:
880196671898
4,1083,17508259165,-;R10: R11: R12:
880406c2e000
4,1084,17508259191,-;R13: 8a11 R14: 8803b5aa1200 R15:
0001
4,1085,17508259218,-;FS: () GS:88041f20()
knlGS:
4,1086,17508259248,-;CS: 0010 DS: ES: CR0: 80050033
4,1087,17508259270,-;CR2: 026f0390 CR3: 01a0b000 CR4:
000407f0
4,1088,17508259297,-;DR0: DR1: DR2:
4,1089,17508259323,-;DR3: DR6: 0ff0 DR7:
0400
4,1090,17508259350,-;Process btrfs-endio-wri (pid: 7212, threadinfo
88019667, task 8801b82e5400)
4,1091,17508259383,-;Stack:
4,1092,17508259391,-; 8801ee8d38f0 880021b6f360 88013a5b2000
8a11
4,1093,17508259423,-; 8802d0a14000 81167606 0246
8801ee8d33b0
4,1094,17508259455,-; 880406c2e000 8801966719bf 880021b6f360
4,1095,17508259488,-;Call Trace:
4,1096,17508259500,-; [81167606] ?
btrfs_search_old_slot+0x543/0x61e
4,1097,17508259526,-; [811692de] ? btrfs_next_old_leaf+0x8a/0x332
4,1098,17508259552,-; [811c484a] ?
__resolve_indirect_refs+0x2d8/0x408
4,1099,17508259578,-; [811c533b] ? find_parent_nodes+0x9c1/0xcec
4,1100,17508259602,-; [811c5e06] ?
iterate_extent_inodes+0xf1/0x23c
4,1101,17508259628,-; [811837b9] ? btrfs_real_readdir+0x482/0x482
4,1102,17508259652,-; [81194db7] ?
release_extent_buffer.isra.19+0x27/0x88
4,1103,17508259679,-; [811837b9] ? btrfs_real_readdir+0x482/0x482
Re: hard freezes with 3.9.0 during io-intensive loads
On Sun, May 5, 2013 at 10:10 AM, Kai Krakow hurikhan77+bt...@gmail.com wrote:
Hello list,
Kai Krakow hurikhan77+bt...@gmail.com schrieb:
I've upgraded to 3.9.0 mainly for the snapshot-aware defragging patches.
I'm running bedup[1] on a regular basis and it is now the third time that
I got back to my PC just to find it hard-frozen and I needed to use the
reset button.
It looks like this happens only while running bedup on my two btrfs
filesystems but I'm not sure if it happens for any of the filesystems or
only one. This is my setup:
# cat /etc/fstab (shortened)
UUID=d2bb232a-2e8f-4951-8bcc-97e237f1b536 / btrfs
compress=lzo,subvol=root64 0 1 # /dev/sd{a,b,c}3
LABEL=usb-backup /mnt/private/usb-backup btrfs noauto,compress-
force=zlib,subvolid=0,autodefrag,comment=systemd.automount 0 0 # external
usb3 disk
# btrfs filesystem show
Label: 'usb-backup' uuid: 7038c8fa-4293-49e9-b493-a9c46e5663ca
Total devices 1 FS bytes used 1.13TB
devid1 size 1.82TB used 1.75TB path /dev/sdd1
Label: 'system' uuid: d2bb232a-2e8f-4951-8bcc-97e237f1b536
Total devices 3 FS bytes used 914.43GB
devid3 size 927.26GB used 426.03GB path /dev/sdc3
devid2 size 927.26GB used 426.03GB path /dev/sdb3
devid1 size 927.26GB used 427.07GB path /dev/sda3
Btrfs v0.20-rc1
Since the system hard-freezes I have no messages from dmesg. But I suspect
it to be related to the defragmentation option in bedup (I've switched to
bedub with --defrag since 3.9.0, and autodefrag for the backup drive).
Just in case, I'm going to try without this option now and see if it won't
freeze.
I was able to take a physical screenshot with a real camera of a kernel
backtrace one time when the freeze happened. I wonder if it is useful to
you and where to send it. I just don't want to upload jpegs right here to
the list without asking first.
The big plus is: Altough I had to hard-reset the frozen system several
times now, btrfs survived the procedure without any impact (just boot
times increases noticeably, probably due to log-replays or something). So
thumbs up for the developers on that point.
Thanks to the great cwillu netcat service here's my backtrace:
4,1072,17508258745,-;[ cut here ]
2,1073,17508258772,-;kernel BUG at fs/btrfs/ctree.c:1144!
4,1074,17508258791,-;invalid opcode: [#1] SMP
4,1075,17508258811,-;Modules linked in: bnep bluetooth af_packet vmci(O)
vmmon(O) vmblock(O) vmnet(O) vsock reiserfs snd_usb_audio snd_usbmidi_lib
snd_rawmidi snd_seq_device gspca_sonixj gpio_ich gspca_main videodev
coretemp hwmon kvm_intel kvm crc32_pclmul crc32c_intel 8250 serial_core
lpc_ich microcode mfd_core i2c_i801 pcspkr evdev usb_storage zram(C) unix
4,1076,17508258966,-;CPU 0
4,1077,17508258977,-;Pid: 7212, comm: btrfs-endio-wri Tainted: G C O
3.9.0-gentoo #2 To Be Filled By O.E.M. To Be Filled By O.E.M./Z68 Pro3
4,1078,17508259023,-;RIP: 0010:[81161d12] [81161d12]
__tree_mod_log_rewind+0x4c/0x121
4,1079,17508259064,-;RSP: 0018:8801966718e8 EFLAGS: 00010293
4,1080,17508259085,-;RAX: 0003 RBX: 8801ee8d33b0 RCX:
880196671888
4,1081,17508259112,-;RDX: 0a4596a4 RSI: 0eee RDI:
8804087be700
4,1082,17508259138,-;RBP: 0071 R08: 1000 R09:
880196671898
4,1083,17508259165,-;R10: R11: R12:
880406c2e000
4,1084,17508259191,-;R13: 8a11 R14: 8803b5aa1200 R15:
0001
4,1085,17508259218,-;FS: () GS:88041f20()
knlGS:
4,1086,17508259248,-;CS: 0010 DS: ES: CR0: 80050033
4,1087,17508259270,-;CR2: 026f0390 CR3: 01a0b000 CR4:
000407f0
4,1088,17508259297,-;DR0: DR1: DR2:
4,1089,17508259323,-;DR3: DR6: 0ff0 DR7:
0400
4,1090,17508259350,-;Process btrfs-endio-wri (pid: 7212, threadinfo
88019667, task 8801b82e5400)
4,1091,17508259383,-;Stack:
4,1092,17508259391,-; 8801ee8d38f0 880021b6f360 88013a5b2000
8a11
4,1093,17508259423,-; 8802d0a14000 81167606 0246
8801ee8d33b0
4,1094,17508259455,-; 880406c2e000 8801966719bf 880021b6f360
4,1095,17508259488,-;Call Trace:
4,1096,17508259500,-; [81167606] ?
btrfs_search_old_slot+0x543/0x61e
4,1097,17508259526,-; [811692de] ? btrfs_next_old_leaf+0x8a/0x332
4,1098,17508259552,-; [811c484a] ?
__resolve_indirect_refs+0x2d8/0x408
4,1099,17508259578,-; [811c533b] ? find_parent_nodes+0x9c1/0xcec
4,1100,17508259602,-; [811c5e06] ?
iterate_extent_inodes+0xf1/0x23c
4,1101,17508259628,-; [811837b9] ? btrfs_real_readdir+0x482/0x482
4,1102,17508259652,-; [81194db7] ?
Re: hard freezes with 3.9.0 during io-intensive loads
On Sun, May 05, 2013 at 04:25:45AM -0600, Kai Krakow wrote:
Hello list,
I've upgraded to 3.9.0 mainly for the snapshot-aware defragging patches. I'm
running bedup[1] on a regular basis and it is now the third time that I got
back to my PC just to find it hard-frozen and I needed to use the reset
button.
It looks like this happens only while running bedup on my two btrfs
filesystems but I'm not sure if it happens for any of the filesystems or
only one. This is my setup:
# cat /etc/fstab (shortened)
UUID=d2bb232a-2e8f-4951-8bcc-97e237f1b536 / btrfs compress=lzo,subvol=root64
0 1 # /dev/sd{a,b,c}3
LABEL=usb-backup /mnt/private/usb-backup btrfs noauto,compress-
force=zlib,subvolid=0,autodefrag,comment=systemd.automount 0 0 # external
usb3 disk
# btrfs filesystem show
Label: 'usb-backup' uuid: 7038c8fa-4293-49e9-b493-a9c46e5663ca
Total devices 1 FS bytes used 1.13TB
devid1 size 1.82TB used 1.75TB path /dev/sdd1
Label: 'system' uuid: d2bb232a-2e8f-4951-8bcc-97e237f1b536
Total devices 3 FS bytes used 914.43GB
devid3 size 927.26GB used 426.03GB path /dev/sdc3
devid2 size 927.26GB used 426.03GB path /dev/sdb3
devid1 size 927.26GB used 427.07GB path /dev/sda3
Btrfs v0.20-rc1
Since the system hard-freezes I have no messages from dmesg. But I suspect
it to be related to the defragmentation option in bedup (I've switched to
bedub with --defrag since 3.9.0, and autodefrag for the backup drive). Just
in case, I'm going to try without this option now and see if it won't
freeze.
I was able to take a physical screenshot with a real camera of a kernel
backtrace one time when the freeze happened. I wonder if it is useful to you
and where to send it. I just don't want to upload jpegs right here to the
list without asking first.
The big plus is: Altough I had to hard-reset the frozen system several times
now, btrfs survived the procedure without any impact (just boot times
increases noticeably, probably due to log-replays or something). So thumbs
up for the developers on that point.
[1]: https://github.com/g2p/bedup
Can you please file a bug for this issue on bugzilla.kernel.org so I can make
sure we don't lose track of it? Make sure the component is set to Btrfs.
Thanks,
Josef
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
