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 try to reproduce. Which raid level did you use for data? If not raid1, could you try with raid1? ;) -chris -- 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: [PATCH] Fix possible pointer dereference
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 handled properly higher up anyways. Proper out of memory handling needs much more work, one liners don't really help. -Andi -- a...@linux.intel.com -- Speaking for myself only. -- 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
[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 --- 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:00.329132291 +0200 @@ -147,6 +147,9 @@ int btrfs_insert_dir_item(struct btrfs_t key.offset = btrfs_name_hash(name, name_len); path = btrfs_alloc_path(); + if (!path) + return -ENOMEM; + path->leave_spinning = 1; data_size = sizeof(*dir_item) + name_len; -- 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
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 (rw,noatime,compress,nocompress,blah,foo,bar) -- Tomasz Chmielewski http://wpkg.org -- 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
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 3262812575 [25765.340530] btrfs csum failed ino 260 off 118784 csum 2566472073 private 1515197691 [25765.340560] btrfs csum failed ino 260 off 114688 csum 2566472073 private 1467250717 [25765.340589] btrfs csum failed ino 260 off 110592 csum 2566472073 private 551456760 [25765.340618] btrfs csum failed ino 260 off 106496 csum 2566472073 private 2751401677 [25765.340647] btrfs csum failed ino 260 off 102400 csum 2566472073 private 2648834377 [25765.340675] btrfs csum failed ino 260 off 98304 csum 2566472073 private 467965630 [25765.340703] btrfs csum failed ino 260 off 94208 csum 2566472073 private 3164409631 [25765.340732] btrfs csum failed ino 260 off 90112 csum 2566472073 private 2042500030 [25765.340760] btrfs csum failed ino 260 off 86016 csum 2566472073 private 830495785 [25809.292651] btrfs: relocating block group 3541041152 flags 9 [25809.416493] __ratelimit: 158 callbacks suppressed [25809.416498] btrfs csum failed ino 257 off 61440 csum 2566472073 private 1989812792 [25809.416537] btrfs csum failed ino 257 off 57344 csum 2566472073 private 3105762401 [25809.416603] btrfs csum failed ino 257 off 53248 csum 2566472073 private 2215503813 [25809.416719] btrfs csum failed ino 257 off 323584 csum 2566472073 private 883932373 [25809.416731] btrfs csum failed ino 257 off 49152 csum 2566472073 private 1747807236 [25809.416752] btrfs csum failed ino 257 off 319488 csum 2566472073 private 2519068844 [25809.416774] btrfs csum failed ino 257 off 45056 csum 2566472073 private 3487590687 [25809.416783] btrfs csum failed ino 257 off 315392 csum 2566472073 private 2599709027 [25809.416813] btrfs csum failed ino 257 off 311296 csum 2566472073 private 157132003 [25809.416823] btrfs csum failed ino 257 off 40960 csum 2566472073 private 599615997 [25809.657271] [ cut here ] [25809.657294] WARNING: at fs/btrfs/relocation.c:3588 btrfs_relocate_block_group+0x27f/0x390 [btrfs]() [25809.657298] Hardware name: System Product Name [25809.657300] Modules linked in: btrfs loop crc32c libcrc32c ppp_deflate zlib_deflate bsd_comp ppp_async crc_ccitt ppp_generic slhc kvm_intel kvm i915 snd_ca0106 snd_rawmidi drm_kms_helper cfbcopyarea snd_ac97_codec ac97_bus video snd_pcm_oss snd_mixer_oss snd_pcm backlight snd_timer cfbimgblt snd processor button cfbfillrect intel_agp wacom soundcore snd_page_alloc usbhid fan fuse ehci_hcd uhci_hcd thermal thermal_sys usbcore atl1 mii [last unloaded: btrfs] [25809.657350] Pid: 15354, comm: btrfs-vol Not tainted 2.6.32-rc3 #1 [25809.657353] Call Trace: [25809.657361] [] warn_slowpath_common+0x7b/0xc0 [25809.657366] [] warn_slowpath_null+0x14/0x20 [25809.657377] [] btrfs_relocate_block_group+0x27f/0x390 [btrfs] [25809.657390] [] btrfs_relocate_chunk+0x8b/0x5e0 [btrfs] [25809.657404] [] ? map_extent_buffer+0xdb/0xe0 [btrfs] [25809.657417] [] ? unmap_extent_buffer+0x13/0x40 [btrfs] [25809.657431] [] ? btrfs_item_offset+0xe4/0xf0 [btrfs] [25809.657444] [] btrfs_balance+0x1ef/0x27
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! -chris -- 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: [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 fragmented, but has a
> > decent amount of free space.
> > 2) Start to commit a transaction
> > 3) Have the commit try and empty out some of the delalloc inodes with
> > extents that are relatively large.
> >
> > The inodes will not be able to make the allocations because they will ask
> > for allocations larger than a contiguous area in the free space cache. So
> > we will wait for more progress to be made on the block group, but since
> > we're in a commit the caching kthread won't make any more progress and it
> > already has enough free space that wait_block_group_cache_progress will
> > just return. So, if we wait and fail to make the allocation the next time
> > around, just loop and go to the next block group. This keeps us from
> > getting stuck in a softlockup. Thanks,
> >
> > Signed-off-by: Josef Bacik
> > ---
> > fs/btrfs/extent-tree.c | 23 +--
> > 1 files changed, 17 insertions(+), 6 deletions(-)
> >
> > diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
> > index b259db3..e46b0b9 100644
> > --- a/fs/btrfs/extent-tree.c
> > +++ b/fs/btrfs/extent-tree.c
> > @@ -3816,6 +3816,7 @@ static noinline int find_free_extent(struct
> > btrfs_trans_handle *trans, int loop = 0;
> > bool found_uncached_bg = false;
> > bool failed_cluster_refill = false;
> > + bool failed_alloc = false;
> >
> > WARN_ON(num_bytes < root->sectorsize);
> > btrfs_set_key_type(ins, BTRFS_EXTENT_ITEM_KEY);
> > @@ -4020,14 +4021,23 @@ refill_cluster:
> >
> > offset = btrfs_find_space_for_alloc(block_group, search_start,
> > num_bytes, empty_size);
> > - if (!offset && (cached || (!cached &&
> > - loop == LOOP_CACHING_NOWAIT))) {
> > - goto loop;
> > - } else if (!offset && (!cached &&
> > - loop > LOOP_CACHING_NOWAIT)) {
> > + /*
> > +* If we didn't find a chunk, and we haven't failed on this
> > +* block group before, and this block group is in the middle of
> > +* caching and we are ok with waiting, then go ahead and wait
> > +* for progress to be made, and set failed_alloc to true.
> > +*
> > +* If failed_alloc is true then we've already waited on this
> > +* block group once and should move on to the next block group.
> > +*/
> > + if (!offset && !failed_alloc && !cached &&
> > + loop > LOOP_CACHING_NOWAIT) {
> > wait_block_group_cache_progress(block_group,
> > - num_bytes + empty_size);
> > + num_bytes + empty_size);
> > + failed_alloc = true;
> > goto have_block_group;
> > + } else if (!offset) {
> > + goto loop;
> > }
> > checks:
> > search_start = stripe_align(root, offset);
> > @@ -4075,6 +4085,7 @@ checks:
> > break;
> > loop:
> > failed_cluster_refill = false;
> > + failed_alloc = false;
> > btrfs_put_block_group(block_group);
> > }
> > up_read(&space_info->groups_sem);
> >
>
> 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.
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
[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 */
#define BTRFS_CSUM_TYPE_CRC32 0
-
-/* csum types */
-#define BTRFS_CSUM_TYPE_CRC32 0
-
static int btrfs_csum_sizes[] = { 4, 0 };
/* four bytes for CRC32 */
--
1.6.5.rc1
--
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
