From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: bug when using 4K sectors? Date: Sun, 16 Sep 2012 09:31:16 +0100 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Joseph Glanville , Konrad Rzeszutek Wilk Cc: James Harper , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On 16/09/2012 08:00, "Joseph Glanville" wrote: > After reading through blkback it appears that it can only support 512 > byte sector sizes and removing this limitation would take quite abit > of work. > It uses hard coded bitshifts pervasively to convert between number of > requests/pages and size of sectors etc. (that is all the >> 9 > everywhere) > > I am going to see what I can about working on getting it to support 4k > sectors too and eventually uncoupled logical/physical sizes but that > would take even more work as far as I can tell. > > Being able to use 4k sectors seems like it would provide pretty > massive gains in performance just by being more efficient let alone > increasing byte aligned writes to the underlying block storage system. The PV blk transport may be based on 512-byte sectors, but the real sector size is communicated between blkfront and blkback via xenbus (field 'sector-size') and blkfront is expected to only make requests that are multiple of, and aligned according to, that real 'sector-size'. I would kind of expect it to work, as CD-ROMs have a larger sector size (2kB IIRC) and we support those... Bashing your head against the PV blk transport code may be premature. ;) -- Keir