From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MOBpX-0008UZ-I0 for qemu-devel@nongnu.org; Tue, 07 Jul 2009 10:39:35 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MOBpS-0008So-H5 for qemu-devel@nongnu.org; Tue, 07 Jul 2009 10:39:35 -0400 Received: from [199.232.76.173] (port=51980 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MOBpS-0008Si-Ba for qemu-devel@nongnu.org; Tue, 07 Jul 2009 10:39:30 -0400 Received: from mail2.shareable.org ([80.68.89.115]:34773) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MOBpR-0004xC-Tz for qemu-devel@nongnu.org; Tue, 07 Jul 2009 10:39:30 -0400 Date: Tue, 7 Jul 2009 15:39:25 +0100 From: Jamie Lokier Subject: Re: [Qemu-devel] bidirectional data exchange between guest and host without network Message-ID: <20090707143925.GA14392@shareable.org> References: <59673.89.3.148.243.1246956346.squirrel@webmail.aql.fr> <20090707090213.GB5690@shareable.org> <53352.89.3.148.243.1246972290.squirrel@webmail.aql.fr> <20090707141204.GL15751@csclub.uwaterloo.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090707141204.GL15751@csclub.uwaterloo.ca> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Lennart Sorensen Cc: Anthony Lannuzel , qemu-devel@nongnu.org Lennart Sorensen wrote: > Most filesystems do not support simultanious mounting. Besides, allowing > multiple mounts at once would make any use of caching imposible. > Almost certainly what you are seeing is caused by caching since each > OS has no reason to believe what it read before isn't still valid so it > uses the cache. After all it is normally safe to assume that the data > on disk can't change unless you write to it. > > Some filesystems probably exist for high availability use to allow a > SAN to be mounted in multiple places at once. Those filesystems generally communicate with each other over the network, so that cache coherency is managed by that communication. Another way to do it is add a cache coherency protocol to the "disk", in addition to the usual read and write I/O operations. I'm not aware of any SAN or shared storage which provides a cache coherency protocol (though I'd be surprised if there isn't one). There are several Linux filesystems designed for clusters which can share a SAN provided they can communicate cache coherency & locking information with each other over a network. -- Jamie