[PATCH] btrfs-progs: Double definition of BTRFS_CSUM_TYPE_CRC32

Clean up multiple definition of BTRFS_CSUM_TYPE_CRC32 in ctree.h. --- ctree.h |4 1 files changed, 0 insertions(+), 4 deletions(-) diff --git a/ctree.h b/ctree.h index a9062ea..fec0d9e 100644 --- a/ctree.h +++ b/ctree.h @@ -108,10 +108,6 @@ struct btrfs_trans_handle; /* csum types */

Re: [PATCH] Btrfs: fix possible softlockup in the allocator

On Tue, Oct 06, 2009 at 08:14:55AM +0200, Johannes Hirte wrote: Am Montag 05 Oktober 2009 21:30:39 schrieb Josef Bacik: Like the cluster allocating stuff, we can lockup the box with the normal allocation path. This happens when we 1) Start to cache a block group that is severely

Re: [PATCH] Btrfs: fix possible softlockup in the allocator

On Tue, Oct 06, 2009 at 09:29:42AM -0400, Josef Bacik wrote: My box survived 6h of dbench with this patch whereas without it hangs within the first thwo minutes. Great, I'm glad it fixed it for you. Thanks for testing and reporting it. Pushed out to the master branch. Thanks!

Warning and BUG using btrfs-vol -b

I was playing with btrfs with 2 files of 3.5 GB (using loop), I completely zeroed one of the files. As expected, I had checksum failures, and I run btrfs-vol -b just to see what happened, and I got this (using -rc3): [25765.340492] btrfs csum failed ino 260 off 122880 csum 2566472073 private

disabling compression, or specifying invalid mount options

Is there a way to disable compression? # mount -o remount,nocompress /mnt/btrfs # Not sure if it worked, so let's do: # mount -o remount,blah,foo,bar /mnt/btrfs/ # Hmm. Is it expected (long term)? # mount (...) /dev/sdb4 on /mnt/btrfs type btrfs

[PATCH] Fix possible pointer dereference

We should always check btrfs_alloc_path(). Some places BUG(), others return -ENOMEM, btrfs_insert_dir_item() seems like it can return safely. Signed-off-by: Diego Calleja dieg...@gmail.com --- linux/fs/btrfs/dir-item.c.BAK 2009-10-06 19:00:48.887361896 +0200 +++ linux/fs/btrfs/dir-item.c

Re: [PATCH] Fix possible pointer dereference

Diego Calleja dieg...@gmail.com writes: We should always check btrfs_alloc_path(). Some places BUG(), others return -ENOMEM, btrfs_insert_dir_item() seems like it can return safely. The problem is that all the callers don't handle errors. It doesn't make sense to fix it low-level currently

Re: Warning and BUG using btrfs-vol -b

On Tue, Oct 06, 2009 at 08:48:32PM +0200, Diego Calleja wrote: I was playing with btrfs with 2 files of 3.5 GB (using loop), I completely zeroed one of the files. As expected, I had checksum failures, and I run btrfs-vol -b just to see what happened, and I got this (using -rc3): Thanks, I'll