From mboxrd@z Thu Jan 1 00:00:00 1970 From: Killian De Volder Subject: Re: Xen and 4K Sectors (was blkback and bcache) Date: Wed, 29 Aug 2012 09:28:29 +0200 Message-ID: <503DC49D.4090903@scarlet.be> References: <503D3646.7020800@abpni.co.uk> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8507634150989229098==" Return-path: In-Reply-To: <503D3646.7020800@abpni.co.uk> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org This is a multi-part message in MIME format. --===============8507634150989229098== Content-Type: multipart/alternative; boundary="------------010405020904080804050701" This is a multi-part message in MIME format. --------------010405020904080804050701 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Word of warning: Since you are messing with 4k size bocks: If you add a 4k dm device to a 512b dm device, the dm becomes a 4k device. If you combine this with a phy:// disk and you are using a Windows it starts trashing your data. I don't think this bug has been fixed yet, but strictly speaking, it's windows not supporting block-size changes on the fly. On 28-08-12 23:21, Jonathan Tripathy wrote: > On Mon, Aug 13, 2012 at 01:25:07PM +0000, James Harper wrote: > >/ > / > >/ > I think the problem is definitely related to the 4K sector issue./ > >/ > / > >/ > qemu appears to always present 512 byte sectors, thus only booting from a/ > >/ > 512 byte sector partition table. Once the PV drivers take over though it all/ > >/ > falls down because PV drivers are passed a 4K sector size and nothing/ > >/ > matches up anymore./ > >/ > > > /Hi James, > > I'm curious as to how you came to the conclusion that qemu always presents 512 byte sectors? > When using bcache formatted to a 4k sector size, Windows Server 2008 just flat out refuses to install... > This is true regardless of whether I'm passing an LV directly to the DomU (phy), or whether I'm using tap::aio or file. > > When formatting the bcache to 512 byte size, Windows tries to install. I say "tries" as then my system kernel > panics and reboots, but that's a bcache issue (I've posted the trace to the bcache list). > > Thanks > > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel --------------010405020904080804050701 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Word of warning:
Since you are messing with 4k size bocks:

If you add a 4k dm device to a 512b dm device, the dm becomes a 4k device.
If you combine this with a phy:// disk and you are using a Windows it starts trashing your data.

I don't think this bug has been fixed yet, but strictly speaking, it's windows not supporting block-size changes on the fly.

On 28-08-12 23:21, Jonathan Tripathy wrote: 
On Mon, Aug 13, 2012 at 01:25:07PM +0000, James Harper wrote:
> > 
> > I think the problem is definitely related to the 4K sector issue.
> > 
> > qemu appears to always present 512 byte sectors, thus only booting from a
> > 512 byte sector partition table. Once the PV drivers take over though it all
> > falls down because PV drivers are passed a 4K sector size and nothing
> > matches up anymore.
> > 

Hi James,

I'm curious as to how you came to the conclusion that qemu always presents 512 byte sectors? 
When using bcache formatted to a 4k sector size, Windows Server 2008 just flat out refuses to install...
This is true regardless of whether I'm passing an LV directly to the DomU (phy), or whether I'm using tap::aio or file.

When formatting the bcache to 512 byte size, Windows tries to install. I say "tries" as then my system kernel 
panics and reboots, but that's a bcache issue (I've posted the trace to the bcache list).

Thanks






_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------010405020904080804050701-- --===============8507634150989229098== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============8507634150989229098==--