Re: Xen and 4K Sectors (was blkback and bcache)

[Killian De Volder <killian.de.volder@scarlet.be>]

[-- Attachment #1.1: Type: text/plain, Size: 1557 bytes --]

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


[-- Attachment #1.2: Type: text/html, Size: 2663 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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