From mboxrd@z Thu Jan 1 00:00:00 1970 From: Frederik Thuysbaert Subject: Re: [Xen-devel] Xen blktap driver for Ceph RBD : Anybody wants to test ? :p Date: Wed, 14 Aug 2013 10:43:37 +0200 Message-ID: <520B4339.6090209@gmail.com> References: <20130419064524.GQ11427@reaktio.net> <6035A0D088A63A46850C3988ED045A4B62D9DA64@BITCOM1.int.sbss.com.au> <6035A0D088A63A46850C3988ED045A4B62E86BF8@BITCOM1.int.sbss.com.au> <6035A0D088A63A46850C3988ED045A4B62F433FE@BITCOM1.int.sbss.com.au> <6035A0D088A63A46850C3988ED045A4B62F43442@BITCOM1.int.sbss.com.au> <6035A0D088A63A46850C3988ED045A4B63891798@BITCOM1.int.sbss.com.au> <6035A0D088A63A46850C3988ED045A4B6389552A@BITCOM1.int.sbss.com.au> <520A4945.1030907@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from mail-wg0-f42.google.com ([74.125.82.42]:50826 "EHLO mail-wg0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759410Ab3HNInl (ORCPT ); Wed, 14 Aug 2013 04:43:41 -0400 Received: by mail-wg0-f42.google.com with SMTP id j13so3441255wgh.3 for ; Wed, 14 Aug 2013 01:43:40 -0700 (PDT) In-Reply-To: Sender: ceph-devel-owner@vger.kernel.org List-ID: To: Sylvain Munaut Cc: James Harper , =?ISO-8859-1?Q?Pasi_K?= =?ISO-8859-1?Q?=E4rkk=E4inen?= , "ceph-devel@vger.kernel.org" , "xen-devel@lists.xen.org" On 13-08-13 17:39, Sylvain Munaut wrote: > Hi, > >> I have been testing this a while now, and just finished testing your >> untested patch. The rbd caching problem still persists. > Yes, I wouldn't expect to change anything for caching. But I still > don't understand why caching would change anything at all ... all of > it should be handled within the librbd lib. > > > Note that I would recommend against caching anyway. The blktap layer > doesn't pass through the FLUSH commands and so this make it completely > unsafe because the VM will think things are commited to disk durably > even though they are not ... > > > >> I will give the error messages of both dom0 and domU before and after I >> applied the patch. > It's actually strange that it changes anything at all. > > Can you try adding a ERROR("HERE\n"); in that error path processing > and check syslog to see if it's triggered at all ? I did this, and can confirm that it is not triggered. > > A traceback would be great if you can get a core file. And possibly > compile tapdisk with debug symbols. I'm not quite sure what u mean, can u give some more information on how I do this? I compiled tapdisk with ./configure CFLAGS=-g, but I'm not sure this is what u meant. > > Cheers, > > Sylvain Regards - Frederik