This should cover most cases I think.
I'll have to break this out into different patches, and maybe clean up
things a bit (there's certainly comments missing and some repetition).
But this boots on my test box and builds a kernel without generating a
single WARN -- big improvement over not
On Fri, Aug 01, 2014 at 04:56:27PM +0400, Ilya Dryomov wrote:
I'm going to fix up rbd_request_fn(), but I want to make sure
I understand this in full.
- Previously the danger of calling blocking primitives on the way to
schedule(), i.e. with task-state != TASK_RUNNING, was that if the
On Thu, Jul 31, 2014 at 02:16:37PM +0400, Ilya Dryomov wrote:
This reverts commit 34c6bc2c919a55e5ad4e698510a2f35ee13ab900.
This commit can lead to deadlocks by way of what at a high level
appears to look like a missing wakeup on mutex_unlock() when
CONFIG_MUTEX_SPIN_ON_OWNER is set, which
On Thu, Jul 31, 2014 at 04:37:29PM +0400, Ilya Dryomov wrote:
This didn't make sense to me at first too, and I'll be happy to be
proven wrong, but we can reproduce this with rbd very reliably under
higher than usual load, and the revert makes it go away. What we are
seeing in the rbd
and possibly wait_event*() too.
---
Subject: locking/mutex: Add debug check for task state
Calling blocking locks with current-state != TASK_RUNNING is a bug.
Signed-off-by: Peter Zijlstra pet...@infradead.org
---
kernel/locking/mutex.c | 11 +++
1 file changed, 11 insertions(+)
diff
On Thu, Jul 31, 2014 at 04:30:52PM +0200, Mike Galbraith wrote:
On Thu, 2014-07-31 at 15:13 +0200, Peter Zijlstra wrote:
Smells like maybe current-state != TASK_RUNNING
Bingo
[ 1200.851004] kjournald D 0002 0 4398 2
0x
[ 1200.858283
On 06/04/2014 12:24 PM, Arnd Bergmann wrote:
For other timekeeping stuff in the kernel, I agree that using some
64-bit representation (nanoseconds, 32/32 unsigned seconds/nanoseconds,
...) has advantages, that's exactly the point I was making earlier
against simply extending the internal
On 06/02/2014 12:19 PM, Arnd Bergmann wrote:
On Monday 02 June 2014 13:52:19 Joseph S. Myers wrote:
On Fri, 30 May 2014, Arnd Bergmann wrote:
a) is this the right approach in general? The previous discussion
pointed this way, but there may be other opinions.
The syscall changes seem like
Typically they are using 64-bit signed seconds.
On May 31, 2014 11:22:37 AM PDT, Richard Cochran richardcoch...@gmail.com
wrote:
On Sat, May 31, 2014 at 05:23:02PM +0200, Arnd Bergmann wrote:
It's an approximation:
(Approximately never ;)
with 64-bit timestamps, you can represent close to
operations director of the Bank of Korea. My name is Peter
Luk. I have an obscured business suggestion for you. I will need you to assist
me in executing a business project from Korea to your country. It involves the
transfer of large sums of money worth 11.5M U.S.D (Eleven Million five hundred
reply through this email
peter.ko...@gmail.com as soon as you receive this email for more details.
Thank you and waiting for your response.
Regards,
Mr Peter Komo.
--
To unsubscribe from this list: send the line unsubscribe ceph-devel in
the body of a message to majord...@vger.kernel.org
More
not sure
what the best way is to recover from this.
Thanks,
Peter
Thanks,
Peter
This is fixed in the cuttlefish branch as of earlier this afternoon.
I've
spent most of the day expanding the automated test suite to include
upgrade combinations to trigger this and *finally* figured out
to share log files etc with
you guys.
Thanks,
Peter
This is fixed in the cuttlefish branch as of earlier this afternoon.
I've
spent most of the day expanding the automated test suite to include
upgrade combinations to trigger this and *finally* figured out that
this
particular problem seems
? Will it influence the daily operations, such as listing
volumes, devices by using ceph commands?
On Sun, Jan 20, 2013 at 1:13 AM, Sage Weil s...@inktank.com wrote:
On Sat, 19 Jan 2013, Dimitri Maziuk wrote:
On 1/19/2013 9:50 AM, Peter Smith wrote:
3. OS recommendation: The OS recommendation page
Or upgrade to 3.7.3 kernel on Precise? Does Inktank test on Ubuntu
12.04 with old kernel or 3.7.3 kernel?
On Sun, Jan 20, 2013 at 8:41 AM, Jeff Mitchell
jeffrey.mitch...@gmail.com wrote:
I'd recommend qemu 1.2+. You'll probably need a newer libvirt than Centos 6
has as well. libvirt 0.10+ is
On 23 November 2012 14:11, Stefan Hajnoczi stefa...@gmail.com wrote:
On Thu, Nov 22, 2012 at 10:07 AM, Stefan Priebe s.pri...@profihost.ag wrote:
diff --git a/block/rbd.c b/block/rbd.c
index 5a0f79f..0384c6c 100644
--- a/block/rbd.c
+++ b/block/rbd.c
@@ -69,7 +69,7 @@ typedef enum {
On 22 November 2012 08:23, Stefan Priebe - Profihost AG
s.pri...@profihost.ag wrote:
Am 21.11.2012 23:32, schrieb Peter Maydell:
Looking at the librbd API (which is what the size and ret
values come from), it uses size_t and ssize_t for these.
So I think probably ssize_t is the right type
On 21 November 2012 17:03, Stefan Weil s...@weilnetz.de wrote:
Why do you use int64_t instead of off_t?
If the value is related to file sizes, off_t would be a good choice.
Looking at the librbd API (which is what the size and ret
values come from), it uses size_t and ssize_t for these.
So I
I'm attempting to install ceph for the first time on openSUSE 11.2,
using the packages out of factory. I used the wiki page:
http://ceph.newdream.net/wiki/Installing_on_SuSE under the Complex
System part. All appears to be fine other than I cannot seem to find
the 'cfuse' comand/script. A
On Mon, 2010-12-27 at 15:30 -0800, Colin McCabe wrote:
Hi Peter,
The cfuse binary is part of ceph. Normally, it would be installed by
make install. Try re-running configure and make, making sure to
specify ./configure --with-fuse
Also, you might want to consider using the kernel client
stuck-until-reboot when the service fails,
many potential test-configurations involving Ceph are way too dangerous
to try...
Regards,
Peter Niemayer
--
To unsubscribe from this list: send the line unsubscribe ceph-devel in
the body of a message to majord...@vger.kernel.org
More majordomo info
or cabling for the moment...
Regards,
Peter Niemayer
--
To unsubscribe from this list: send the line unsubscribe ceph-devel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
redundant OSDs
b) after a physical failure of one underlying storage device
c) after every disconnect/reconnect of Ceph nodes
?
Regards,
Peter Niemayer
--
To unsubscribe from this list: send the line unsubscribe ceph-devel in
the body of a message to majord...@vger.kernel.org
More majordomo info
23 matches
Mail list logo
