[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-btrfs
Subject:    Re: Indefinite hang in reserve_metadata_bytes on kernel 3.18.3
From:       Holger =?iso-8859-1?q?Hoffst=E4tte?=  <holger.hoffstaette () googlemail ! com>
Date:       2015-01-30 10:02:01
Message-ID: pan.2015.01.30.10.02.01 () googlemail ! com
[Download RAW message or body]

On Thu, 29 Jan 2015 22:50:20 +0000, Steven Schlansker wrote:

> Thank you for the suggestion.  I did not find a 3.18.5 presented in any
> form other than as a large number of *.patch files, so I went for
> 3.19-rc6 instead (which I verified has this commit)

3.18.5 is out now but it shouldn't matter, in your case it looks like 
something else is wrong.

> Now I am getting:
> 
> [ 1224.728313] ------------[ cut here ]------------
> [ 1224.728323] kernel BUG at fs/btrfs/extent-tree.c:7362!

That's -ENOMEM in btrfs_alloc_tree_block(), no definite idea what could 
(really) cause that. In any case your first order of business should be 
to get an up-to-date btrfs-progs (= 3.18.2) and see what a check says. 
Your 3.12 is really old.

Another thing that I found helpful is to mount the fs in question at 
least once without the free-space-cache, aka with -o 
clear_cache,nospace_cache options. btrfs tries to detect whether this 
cache is out of sync/corrupted, but I've seen it lead to weird problems 
down the road on rare occasion. So mount the fs without it, maybe do a 
little cleanup/work, cleanly unmount it and then try to remount/work with 
the cache enabled.

If you first created & worked on this fs with 3.13 you may have other yet 
undetected problems lurking.

That's really all I can recommend for now from here. Good luck!

-h

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]