A second update to this. It seems the problem is that btrfs gets stuck
in an infinite loop while in tree_insert. I'm not sure why yet. Below is
my back trace incase anyone wants to have a look.
[ 9824.393942] SysRq : Show Blocked State
[ 9824.393942] taskPC stack pid father
[ 9
I ran a few tests that Jim suggested and found that btrfs works fine on
2.6.26 as long as there are only 23 or less files on the file system.
Anymore and I experience the lockup. Jim and I will be working to find a
solution but if anyone else has any clues that would be greatly
appreciated.
Lee
On
Lee Trager wrote:
The more and more I look at this problem the more I tend to think that
the issue is because of some change in the way the VFS or something
interacts with the file system. Does anyone know of any big changes? Why
is the inode being marked dirty? Is there some kind of read error.
On Fri, Feb 20, 2009 at 01:25:19PM -0500, jim owens wrote:
> lee,
>
> A couple of thoughts about your .26 lockup:
>
> - I assume you are on the same hardware with 27.
I am.
>
> - Are you using a module or builtin btrfs (I build it in).
>
As a module
> - It looks like you are using vmware... when I'
lee,
A couple of thoughts about your .26 lockup:
- I assume you are on the same hardware with 27.
- Are you using a module or builtin btrfs (I build it in).
- It looks like you are using vmware... when I'm doing kernel
stuff I want to be on the iron, not trusting virtual machine code.
(peo
I have updated my backport patch to apply cleanly to the experimental
btrfs branch as well as fix a couple of mistakes I had. I am still
having lockup issues on 2.6.26. My best guess right now is that there is
some sort of race condition going on. I'm trying to track it down but
I'm not having any
