On Sat, Dec 03, 2011 at 04:36:44PM +0200, Konstantinos Skarlatos wrote:
unfortunately i was wrong. rc4 does not fix this issue for me when
rsyncing large amounts of data...
my mount options:
mount -o loop,compress=zlib,compress-force btrfs_test /storage/btrfs
the filesystem is a file on a
even more kernel messages from btrfs crashing when rsyncing large
amounts of data on 3.2rc4
Dec 3 15:12:14 mail kernel: [15481.100564] loop0 D
00010044b6c5 0 1729 2 0x
Dec 3 15:12:14 mail kernel: [15481.101550] 8801f9b31b30
0046
unfortunately i was wrong. rc4 does not fix this issue for me when
rsyncing large amounts of data...
my mount options:
mount -o loop,compress=zlib,compress-force btrfs_test /storage/btrfs
the filesystem is a file on a raid5 xfs volume.
[15481.098588] INFO: task loop0:1729 blocked for more than
Hi Chris!
Am 01.12.2011 19:41, schrieb Chris Mason:
So, the transaction close is in btrfs_evict_inode, which sounds like a
deadlock recently fixed by this commit:
http://git.kernel.org/?p=linux/kernel/git/mason/linux-btrfs.git;a=commit;h=aa38a711a893accf5b5192f3d705a120deaa81e0
If you pull
On Fri, Dec 02, 2011 at 02:46:48PM +0100, Tobias wrote:
Hi Chris!
Am 01.12.2011 19:41, schrieb Chris Mason:
So, the transaction close is in btrfs_evict_inode, which sounds like a
deadlock recently fixed by this commit:
Hi all
On 2/12/2011 3:46 μμ, Tobias wrote:
Hi Chris!
Am 01.12.2011 19:41, schrieb Chris Mason:
So, the transaction close is in btrfs_evict_inode, which sounds like a
deadlock recently fixed by this commit:
Am 02.12.2011 16:22, schrieb Konstantinos Skarlatos:
So, the transaction close is in btrfs_evict_inode, which sounds like a
deadlock recently fixed by this commit:
http://git.kernel.org/?p=linux/kernel/git/mason/linux-btrfs.git;a=commit;h=aa38a711a893accf5b5192f3d705a120deaa81e0
If you pull
I see they got into 3.2rc4, so I am now compiling it. I will report
back in a few hours
On Παρασκευή, 2 Δεκέμβριος 2011 5:48:31 μμ, Tobias wrote:
Am 02.12.2011 16:22, schrieb Konstantinos Skarlatos:
So, the transaction close is in btrfs_evict_inode, which sounds like a
deadlock recently fixed
After about 1TB of rsyncs from multiple servers at the same time, plus
some heavy filesystem loading, i believe that 3.2rc4 solves the problem
for me. Now if only we had deduplication and an fsck tool :)
On Παρασκευή, 2 Δεκέμβριος 2011 9:53:10 μμ, Konstantinos Skarlatos
wrote:
I see they got
On Thu, Dec 01, 2011 at 09:20:53AM +0100, Tobias wrote:
Hi Chris
Am 30.11.2011 15:10, schrieb Chris Mason:
We see a bunch of procs stuck waiting to start a transaction, but we
don't see why they are waiting. Could you please capture a sysrq-t
during this? That will show us all the waiters
Am 28.11.2011 10:29, schrieb Chris Samuel:
Hi Tobias,
On Mon, 28 Nov 2011, 19:16:25 EST, Tobiastra...@robotech.de wrote:
The problem occurs on the stock ubuntu kernel 2.6.38-8, 3.0.0-12,
3.0.0-13 and on my self-compiled 3.1.2.
There's a lot of work gone into btrfs in 3.2,
it would be
On Wed, Nov 30, 2011 at 10:44:15AM +0100, Tobias wrote:
Am 28.11.2011 10:29, schrieb Chris Samuel:
Hi Tobias,
On Mon, 28 Nov 2011, 19:16:25 EST, Tobiastra...@robotech.de wrote:
The problem occurs on the stock ubuntu kernel 2.6.38-8, 3.0.0-12,
3.0.0-13 and on my self-compiled 3.1.2.
12 matches
Mail list logo