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

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

[Jonathan Tripathy]

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

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

//




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

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

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

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

[James Harper]

> 
> I'm curious as to how you came to the conclusion that qemu always presents
> 512 byte sectors?

I checked the code. I could be wrong but the value 512 seemed pretty much hardcoded.

> 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).
> 

I'm watching your thread on bcache list too.

Ideally, we'd be able to emulate 512e so windows can know that the underlying block size is 4k and will (in win7 and newer) align to that boundary where possible.

lvm seems pretty flexible wrt block size. I had my lvm with a pv with 4k block size and wanted 512 byte block size, so I split my raid, created a new raid with the now spare disk and created bcache with 512 byte block size, added the 512 byte pv to the lvm (which is now 2 pv's one 512, one 4k), pvmove'd everything across, then removed the 4k pv and joined it to the new raid.
 
James

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

[Killian De Volder]

[-- 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

Xen and 4K Sectors (was blkback and bcache)

[James Harper]

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.

What is the solution here? Do I just tell windows that we have a 512 byte sector and put up with the potential loss of performance?

Thanks

James

> -----Original Message-----
> From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-
> bounces@lists.xen.org] On Behalf Of James Harper
> Sent: Monday, 13 August 2012 5:17 PM
> To: xen-devel@lists.xen.org
> Subject: [Xen-devel] blkback and bcache
> 
> I'm having trouble using blkback under gplpv when the disk is on top of a
> bcache device. My devices are layered as follows:
> 
> /dev/sd[ab]
> md0 (RAID1)
> bcache
> lvm
> 
> It seems that bcache presents a 4K sector size to Linux, which is then
> reflected by lvm and in turn blkback.
> 
> Obviously GPLPV isn't handling 4K sectors correctly... any suggestions as to
> what I might need to do to make this work properly? As a last resort I should
> be able to fake 512 byte sectors to Windows but would prefer that Windows
> knew it was dealing with a device with 4K sectors underneath.
> 
> Thanks
> 
> James
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

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

[James Harper]

> 
> 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.
> 
> What is the solution here? Do I just tell windows that we have a 512 byte
> sector and put up with the potential loss of performance?
> 

I just came across this...

http://support.microsoft.com/kb/982018

I guess Windows doesn't support 4K disks after all, so I'll emulate 512 byte sectors and fake whatever scsi interface is required to tell windows that the disk is 4K but emulating 512 bytes.

James

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

[Pasi Kärkkäinen]

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.
> > 
> > What is the solution here? Do I just tell windows that we have a 512 byte
> > sector and put up with the potential loss of performance?
> > 
> 
> I just came across this...
> 
> http://support.microsoft.com/kb/982018
> 
> I guess Windows doesn't support 4K disks after all, so I'll emulate 512 byte sectors and fake whatever scsi interface is required to tell windows that the disk is 4K but emulating 512 bytes.
> 

At least Linux reports:
/sys/block/<disk>/queue/logical_block_size=512
/sys/block/<disk>/queue/physical_block_size=4096

So I assume you need to set those somehow..

-- Pasi