From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=41501 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ObFVa-0008P1-Ir for qemu-devel@nongnu.org; Tue, 20 Jul 2010 12:17:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1ObFV7-0008Fr-FI for qemu-devel@nongnu.org; Tue, 20 Jul 2010 12:17:04 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]:29591) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ObFV7-0008Et-3i for qemu-devel@nongnu.org; Tue, 20 Jul 2010 12:17:01 -0400 Message-ID: <4C45CBF8.40400@cisco.com> Date: Tue, 20 Jul 2010 10:16:56 -0600 From: "David S. Ahern" MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH] Disable O_DIRECT for physical CDROM/DVD drives References: <1279639056-20465-1-git-send-email-Jes.Sorensen@redhat.com> <4C45C355.2000204@codemonkey.ws> <4C45C87C.4060709@redhat.com> In-Reply-To: <4C45C87C.4060709@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jes Sorensen Cc: qemu-devel@nongnu.org On 07/20/10 10:02, Jes Sorensen wrote: > On 07/20/10 17:40, Anthony Liguori wrote: >> On 07/20/2010 10:17 AM, Jes.Sorensen@redhat.com wrote: >>> From: Jes Sorensen >>> >>> O_DIRECT (cache=none) requires sector alignment, however the physical >>> sector size of CDROM/DVD drives is 2048, as opposed to most disk >>> devices which use 512. QEMU is hard coding 512 all over the place, so >>> allowing O_DIRECT for CDROM/DVD devices does not work. >>> >>> Signed-off-by: Jes Sorensen >>> >> >> Wouldn't a better solution be to have a cdrom_read/cdrom_write hook that >> did the appropriate bouncing? >> >> Silently disabling something a user explicitly asked for is not a good >> option. In the very least, it should error out entirely. > > I thought about this, but it would require basically fixing up or > copying all of the pread/pwrite code to use the right block size. This > is really more of a band-aid but it should be pretty safe. > > Cheers, > Jes > > What about setting the logical and physical block size properties? Is the intent of these to handle varying sizes amongst block devices? David