[PATCH] btrfs-progs: Double definition of BTRFS_CSUM_TYPE_CRC32

2009-10-06 Thread Dirk Gouders
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

2009-10-06 Thread Josef Bacik
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

2009-10-06 Thread Chris Mason
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. Tha

Warning and BUG using btrfs-vol -b

2009-10-06 Thread Diego Calleja
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 326

disabling compression, or specifying invalid mount options

2009-10-06 Thread Tomasz Chmielewski
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 (rw,noatime,compress,nocompress,blah,foo,b

[PATCH] Fix possible pointer dereference

2009-10-06 Thread Diego Calleja
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 --- linux/fs/btrfs/dir-item.c.BAK 2009-10-06 19:00:48.887361896 +0200 +++ linux/fs/btrfs/dir-item.c 2009-10-06 19:01:

Re: [PATCH] Fix possible pointer dereference

2009-10-06 Thread Andi Kleen
Diego Calleja 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 when it cannot be

Re: Warning and BUG using btrfs-vol -b

2009-10-06 Thread Chris Mason
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