On 01/31/2013 08:33 AM, Josef Bacik wrote:
> On Wed, Jan 30, 2013 at 02:37:40PM -0700, Jim Schutt wrote:
>> On 01/30/2013 09:38 AM, Josef Bacik wrote:
>>> On Tue, Jan 29, 2013 at 04:05:17PM -0700, Jim Schutt wrote:
>>>>> On 01/29/2013 01:04 PM, Josef Bacik wrote:
&
On 01/30/2013 09:38 AM, Josef Bacik wrote:
> On Tue, Jan 29, 2013 at 04:05:17PM -0700, Jim Schutt wrote:
>> > On 01/29/2013 01:04 PM, Josef Bacik wrote:
>>> > > On Tue, Jan 29, 2013 at 11:41:10AM -0700, Jim Schutt wrote:
>>>>> > >> > On 01/28/
On 01/29/2013 01:04 PM, Josef Bacik wrote:
> On Tue, Jan 29, 2013 at 11:41:10AM -0700, Jim Schutt wrote:
>> > On 01/28/2013 02:23 PM, Josef Bacik wrote:
>>> > > On Thu, Jan 03, 2013 at 11:44:46AM -0700, Jim Schutt wrote:
>>>> > >> Hi Josef,
>>
On 01/29/2013 01:04 PM, Josef Bacik wrote:
> On Tue, Jan 29, 2013 at 11:41:10AM -0700, Jim Schutt wrote:
>> On 01/28/2013 02:23 PM, Josef Bacik wrote:
>>> On Thu, Jan 03, 2013 at 11:44:46AM -0700, Jim Schutt wrote:
>>>> Hi Josef,
>>>>
>>>> Than
On 01/28/2013 02:23 PM, Josef Bacik wrote:
> On Thu, Jan 03, 2013 at 11:44:46AM -0700, Jim Schutt wrote:
>> Hi Josef,
>>
>> Thanks for the patch - sorry for the long delay in testing...
>>
>
> Jim,
>
> I've been trying to reason out how this
On 01/28/2013 02:23 PM, Josef Bacik wrote:
> On Thu, Jan 03, 2013 at 11:44:46AM -0700, Jim Schutt wrote:
>> Hi Josef,
>>
>> Thanks for the patch - sorry for the long delay in testing...
>>
>
> Jim,
>
> I've been trying to reason out how this
Hi Josef,
Thanks for the patch - sorry for the long delay in testing...
On 12/18/2012 06:52 AM, Josef Bacik wrote:
> On Wed, Dec 12, 2012 at 06:52:37PM -0700, Liu Bo wrote:
>> An user reported that he has hit an annoying deadlock while playing with
>> ceph based on btrfs.
>>
>> Current updating
On 12/11/2012 06:37 PM, Liu Bo wrote:
> On Tue, Dec 11, 2012 at 09:33:15AM -0700, Jim Schutt wrote:
>> On 12/09/2012 07:04 AM, Liu Bo wrote:
>>> On Wed, Dec 05, 2012 at 09:07:05AM -0700, Jim Schutt wrote:
>>> Hi Jim,
>>>
>>> Could you please apply the
On 12/09/2012 07:04 AM, Liu Bo wrote:
> On Wed, Dec 05, 2012 at 09:07:05AM -0700, Jim Schutt wrote:
>> > Hi,
>> >
>> > I'm hitting a btrfs locking issue with 3.7.0-rc8.
>> >
>> > The btrfs filesystem in question is backing a Ceph OSD
&
On 12/05/2012 09:07 AM, Jim Schutt wrote:
Hi,
I'm hitting a btrfs locking issue with 3.7.0-rc8.
The btrfs filesystem in question is backing a Ceph OSD
under a heavy write load from many cephfs clients.
I reported this issue a while ago:
http://www.spinics.net/lists/linux-btrfs/msg19370
Hi,
I'm hitting a btrfs locking issue with 3.7.0-rc8.
The btrfs filesystem in question is backing a Ceph OSD
under a heavy write load from many cephfs clients.
I reported this issue a while ago:
http://www.spinics.net/lists/linux-btrfs/msg19370.html
when I was testing what I thought might be
Hi,
I've been testing what I believe to be the btrfs patches being queued
up for 3.7, and have been having trouble with stalled writes.
(See, e.g., http://www.spinics.net/lists/linux-btrfs/msg19171.html)
With CONFIG_PROVE_LOCKING=y I was able to collect the following
lockdep splat, which I hope
Hi,
I'm hitting the following on a btrfs filesystem used as
a Ceph OSD data store, under a heavy write load.
My kernel is current Linus master (commit 56d27adcb536)
merged with Josef Bacik's btrfs-next master (commit d5b04fb3bbb6).
What can I do to help resolve this?
[ 1558.754105] INFO: task
On 05/03/2012 08:53 AM, Josef Bacik wrote:
On Thu, May 03, 2012 at 08:43:32AM -0600, Jim Schutt wrote:
On 05/01/2012 10:41 AM, Jim Schutt wrote:
On 05/01/2012 10:00 AM, Josef Bacik wrote:
On Wed, Apr 11, 2012 at 02:24:30PM -0600, Jim Schutt wrote:
On 04/11/2012 01:09 PM, Josef Bacik wrote
On 05/01/2012 10:41 AM, Jim Schutt wrote:
On 05/01/2012 10:00 AM, Josef Bacik wrote:
On Wed, Apr 11, 2012 at 02:24:30PM -0600, Jim Schutt wrote:
On 04/11/2012 01:09 PM, Josef Bacik wrote:
On Tue, Apr 10, 2012 at 01:39:14PM -0600, Jim Schutt wrote:
Hi,
I hit this BUG today.
I'm ru
On 05/01/2012 10:00 AM, Josef Bacik wrote:
On Wed, Apr 11, 2012 at 02:24:30PM -0600, Jim Schutt wrote:
On 04/11/2012 01:09 PM, Josef Bacik wrote:
On Tue, Apr 10, 2012 at 01:39:14PM -0600, Jim Schutt wrote:
Hi,
I hit this BUG today.
I'm running 3.3.1 merged with the ceph and btrfs bit
On 04/11/2012 02:28 PM, Josef Bacik wrote:
On Wed, Apr 11, 2012 at 02:24:30PM -0600, Jim Schutt wrote:
On 04/11/2012 01:09 PM, Josef Bacik wrote:
On Tue, Apr 10, 2012 at 01:39:14PM -0600, Jim Schutt wrote:
Hi,
I hit this BUG today.
I'm running 3.3.1 merged with the ceph and btrfs bit
On 04/11/2012 01:09 PM, Josef Bacik wrote:
On Tue, Apr 10, 2012 at 01:39:14PM -0600, Jim Schutt wrote:
Hi,
I hit this BUG today.
I'm running 3.3.1 merged with the ceph and btrfs bits for 3.4,
i.e. 3.3.1 +
commit bc3f116fec194 "Btrfs: update the checks for mixed block group
On 04/10/2012 02:24 PM, Chris Mason wrote:
On Tue, Apr 10, 2012 at 01:39:14PM -0600, Jim Schutt wrote:
Hi,
I hit this BUG today.
I'm running 3.3.1 merged with the ceph and btrfs bits for 3.4,
i.e. 3.3.1 +
commit bc3f116fec194 "Btrfs: update the checks for mixed block group
Hi,
I hit this BUG today.
I'm running 3.3.1 merged with the ceph and btrfs bits for 3.4,
i.e. 3.3.1 +
commit bc3f116fec194 "Btrfs: update the checks for mixed block groups with big
metadata blocks"
commit c01a935b9 "rbd: move snap_rwsem to the device, rename to
header_rwsem"
The btrfs
David Sterba wrote:
On Thu, Sep 15, 2011 at 11:44:09AM -0700, Sage Weil wrote:
On Tue, 13 Sep 2011, Liu Bo wrote:
On 09/11/2011 05:47 AM, Martin Mailand wrote:
Hi
I am hitting this Warning reproducible, the workload is a ceph osd,
kernel ist 3.1.0-rc5.
Have posted a patch for this:
http://m
Jim Schutt wrote:
Hi Miao,
Miao Xie wrote:
Hi, Jim
Could you test the attached patch for me? I have done some quick
tests, it worked well. But I'm not sure if it can fix
the bug you reported or not, so I need your help!
So far I haven't been able to reproduce with your patch
app
e to test for a few more days, though,
before calling it good.
Thanks for the patch -- I'll let you know what more
testing brings.
-- Jim
Thanks
Miao
On fri, 17 Jun 2011 10:10:31 -0600, Jim Schutt wrote:
Hi,
I've hit this delayed-inode BUG several times. I'm using btrfs
a
Hi,
I've hit this delayed-inode BUG several times. I'm using btrfs
as the data store for Ceph OSDs, and testing a heavy write load.
The kernel I'm running is a recent commit (f8f44f09eaa) from
Linus' tree with the for-chris branch (commit ed0ca14021e5) of
git://git.kernel.org/pub/scm/linux/ker
ed by mounting -o flushoncommit and running xfstest
13. It cannot be reproduced with this patch. Thanks,
FWIW, this version of the patch works fine for me
as well.
-- Jim
Reported-by: Jim Schutt
Signed-off-by: Josef Bacik
---
fs/btrfs/transaction.c | 14 +++---
1 files change
Josef Bacik wrote:
On 06/13/2011 05:07 PM, Jim Schutt wrote:
Hi,
On a system under a heavy write load from multiple ceph OSDs,
I'm running into the following hung tasks where btrfs is implicated.
I'm running commit 3c25fa740e2 from Linus' tree merged with
commit cb9b4
Hi,
On a system under a heavy write load from multiple ceph OSDs,
I'm running into the following hung tasks where btrfs is implicated.
I'm running commit 3c25fa740e2 from Linus' tree merged with
commit cb9b41c92fa from git://ceph.newdream.net/git/ceph-client.git.
Let me know what else I can do t
mit_transaction_async should be fine then,
right? When btrfs_commit_transaction runs in the other thread it won't
care that current->journal_info is NULL.
Oh yeah your patch is good :),
Okay cool. Here's the fix with a proper changelog and a
for data, but the cosd process
is logging debug info to an ext3 filesystem, so when I bisected
"mkcephfs fails" to commit 16cdcec736cd21, I assumed it was the
root cause of the above.
What else do I need to do to help sort this out?
-- Jim
On Thu, Jun 09, 2011 at 03:52:43PM -0600, Jim Sc
Hi,
I've run into the following BUG on 3.0-rcX kernels when
running mkcephfs:
Jun 9 15:14:50 an1 [ 299.446615] [ cut here ]
Jun 9 15:14:50 an1 [ 299.447357] kernel BUG at fs/btrfs/ioctl.c:432!
Jun 9 15:14:50 an1 [ 299.447357] invalid opcode: [#1] SMP
Jun 9 15:
Josef Bacik wrote:
On 04/27/2011 02:43 PM, Jim Schutt wrote:
Hi,
I'm not sure if they matter, but I got these warnings on
one of the machines I'm using as a Ceph OSD server:
[ 1806.549469] [ cut here ]
[ 1806.554593] WARNING: at fs/btrfs/extent-t
Josef Bacik wrote:
On 04/27/2011 02:43 PM, Jim Schutt wrote:
Hi,
I'm not sure if they matter, but I got these warnings on
one of the machines I'm using as a Ceph OSD server:
[ 1806.549469] [ cut here ]
[ 1806.554593] WARNING: at fs/btrfs/extent-t
Hi,
I'm not sure if they matter, but I got these warnings on
one of the machines I'm using as a Ceph OSD server:
[ 1806.549469] [ cut here ]
[ 1806.554593] WARNING: at fs/btrfs/extent-tree.c:5790 use_block_rsv+0xa7/0x101
[btrfs]()
[ 1806.562903] Hardware name: PowerEdge
Hi,
I got this kernel BUG on a server running multiple Ceph
cosd instances. I'm not sure what was going on at the
time, as I just noticed this on my serial console for
this node.
It looks like another example of the truncate issue in
Matt Weil's report.
Please let me know what other information
Hi,
On Wed, 2011-01-26 at 10:59 -0700, Jim Schutt wrote:
> Hi,
>
> I got this kernel BUG on a server running multiple Ceph
> cosd instances, during a heavy write load generated by
> multiple Ceph clients.
>
> The server was running the current ceph unstable kernel
>
Hi,
I got this kernel BUG on a server running multiple Ceph
cosd instances, during a heavy write load generated by
multiple Ceph clients.
The server was running the current ceph unstable kernel
(a3f5274e535 in
git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client.git).
Please let me k
36 matches
Mail list logo
