From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: [PATCH] kvm tools: Use mmap for working with disk image V2 Date: Mon, 11 Apr 2011 14:41:02 -0400 Message-ID: <20110411184102.GA5755@infradead.org> References: <1302351248-4853-1-git-send-email-levinsasha928@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: penberg@kernel.org, kvm@vger.kernel.org, linux-fsdevel@vger.kernel.org To: Sasha Levin Return-path: Received: from bombadil.infradead.org ([18.85.46.34]:55867 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755192Ab1DKSlE (ORCPT ); Mon, 11 Apr 2011 14:41:04 -0400 Content-Disposition: inline In-Reply-To: <1302351248-4853-1-git-send-email-levinsasha928@gmail.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: How do you plan to handle I/O errors or ENOSPC conditions? Note that shared writeable mappings are by far the feature in the VM/FS code that is most error prone, including the impossiblity of doing sensible error handling. The version that accidentally used MAP_PRIVATE actually makes a lot of sense for an equivalent of qemu's snapshot mode where the image is readonly and changes are kept private as long as the amount of modified blocks is small enough to not kill the host VM, but using shared writeable mappings just sems dangerous.