Re: postgresql activity causes crash, 2.6.36.1
- Original Message From: Chris Mason chris.ma...@oracle.com Great, this is a known bug in the O_DIRECT code. I'll fix it up tomorrow morning. At the risk of sounding like the non-contributing, annoying moocher that I am, I thought I'd check on the status of this bug. -- 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
postgresql activity causes crash, 2.6.36.1
After a successful db startup, this crash was reproducible every time with db activity, or possibly just time. The filesystem is a raid1 and even after a reformat and restore from backup, the crash remains: Label: slash uuid: a9730db3-a475-45bb-af94-a873e235114b Total devices 2 FS bytes used 39.04GB devid2 size 97.66GB used 48.51GB path /dev/sdb2 devid1 size 97.66GB used 48.53GB path /dev/sda2 mounted as: # mount |grep sdb2 /dev/sdb2 on / type btrfs (rw,noatime) This is transcribed from the screen, so forgive type-o's and blah .Let me know if I skipped something important. (every line starts with [27163.079010] ) Call trace: __btrfs_submit_bio_done+0x1b/0x1d [btrfs] run_one_async_done+0x94/0x98 [btrfs] run_ordered_completions++0x78/0xaa [btrfs] worker_loop+0x199/0x4ec [btrfs] kthread+0x0d/0xa5 kernel_thread_helper+0x4/0x10 ? restore_args+0x0/0x30 ? kthread+0x0/0xa5 ? kernel_thread_helper+0x0/0x10 Code: 74 04 blah blah RIP [blah 7] btrfs_map_bio+0x88/0x1c9 RSP ffbblah ---[ end trace f8blah ]--- -- 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
removing a snapshot that is outside the subvolume directory fails, sorta
Well, it fails the way that I'm trying to do it. kernel:2.6.31.9-174.fc12.x86_64 btrfs-progs: btrfs-progs-0.19-9.fc12.x86_64 On a new filesystem: $ cd /mnt/btrfs1 $ btrfsctl -S subvol1 . operation complete Btrfs Btrfs v0.19 $ btrfsctl -s snapofsubvol1 subvol1 operation complete Btrfs Btrfs v0.19 $ btrfsctl -D snapofsubvol1 subvol1 ioctl:: No such file or directory $ btrfsctl -S subvol2 . operation complete Btrfs Btrfs v0.19 # cd subvol2 $ btrfsctl -s snapofsubvol2 subvol2 operation complete Btrfs Btrfs v0.19 $ btrfsctl -D snapofsubvol2 subvol2 operation complete Btrfs Btrfs v0.19 AHA, I figured it out! $ btrfsctl -D snapofsubvol1 subvol1/.. I don't know if that's the intended syntax or if it's accidental, but I'll go ahead and send this as an FYI if anyone has the same issue. Maybe it's obvious to some, but it wasn't to me. -- 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: snapshot-removal - timeline ?
Hello, is there a timeline for snapshot-removal ? i did intensively play with btrfs about a year ago and was really impressed, but i quit due to the lack of snapshot removal. (i tried btrfs mostly because of the snapshot feature) has there been some progress on this or is there a timeline when this feature will be available ? i wonder if it`s just so hard to implement or if it`s just too low priority on the todo list. maybe both ? ;) Its a little of both ;) The plan is to have this in 2.6.32 Last I heard, someone was saying .31... Is it being moved? Yes, it was delayed so we could finalize the other changes in .31. It's strange that such a small thing should be delayed so much. If snapshot removal was working, I'm quite sure we might get more users and thereby more stable code faster. roy -- I don't know whether it's small in required effort, but I know as a user the feature would be big. I actually have a non-critical, redundant backup system that I was set to install with .31, betting on the snapshot removal. You can't please all the people all the time, but I thought I'd write to voice an opinion for prioritizing it for .32. Thanks. -- 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: new benchmark btrfs 0.19 vs. ext4
Oh ya :). U, whoops. I'll update and email revised charts over to Morten. If you want a more immediate answer, you can look at his original numbers at the beginning of this thread. Just check for it in a couple of days at the same URL's. I don't want to clog up this list with discussion about outdated benchmarks, of which this will soon be. --- On Tue, 7/7/09, Josh Berry d...@condordes.net wrote: From: Josh Berry d...@condordes.net Subject: Re: new benchmark btrfs 0.19 vs. ext4 To: Morten P.D. Stevens mstev...@win-professional.com Cc: Brian Neu proclivit...@yahoo.com, linux-btrfs@vger.kernel.org linux-btrfs@vger.kernel.org Date: Tuesday, July 7, 2009, 9:46 PM On Tue, Jul 7, 2009 at 17:06, Morten P.D. Stevensmstev...@win-professional.com wrote: Hi Brian, thanks for the chart. Here are the results visually for all: http://www2.win-professional.com/images2/btrfs01.png http://www2.win-professional.com/images2/btrfs02.png What are the units? Are those measuring throughput or latency? I read these graphs as saying btrfs is either blazingly fast, blazingly slow, or some combination thereof. ;) -- Josh -- 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
