Re: bug when using 4K sectors?

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Wed, Sep 05, 2012 at 11:56:08PM +0000, James Harper wrote:
> > On Mon, Aug 13, 2012 at 02:12:58PM +0000, James Harper wrote:
> > > I notice this code in drivers/block/xen-blkback/common.h
> > >
> > > #define vbd_sz(_v)      ((_v)->bdev->bd_part ? \
> > >                          (_v)->bdev->bd_part->nr_sects : \
> > >                           get_capacity((_v)->bdev->bd_disk))
> > >
> > > is the value returned by vbd_sz(_v) the number of sectors in the Linux
> > > device (eg size / 4096), or the number of 512 byte sectors? I suspect
> > > the former which is causing block requests beyond 1/8th the size of
> > > the device to fail (assuming 4K sectors are expected to work at all -
> > > I can't quite get my head around how it would be expected to work -
> > > does Linux do the read-modify-write if required?)
> > 
> > I think you need to instrument it to be sure.. But more interesting, do you
> > actually have a disk that exposes a 4KB hardware and logical sector? So far
> > I've only found SSDs that expose a 512kB logical sector but also expose the
> > 4KB hardware.
> > 
> > Never could figure out how that is all suppose to work as the blkback is filled
> > with << 9 on a bunch of things.
> > 
> 
> I was using bcache which does expose a 4K block size, by default. I changed it to 512 and it all works now, although I haven't tested if there is any loss of performance.

OK, let me see how I can setup bcache and play with that.
> 
> Does Xen provide a way to tell Windows that the underlying device is 512e (4K sector with 512 byte emulated interface)? This would keep everything working as is but allow windows to align writes to 4K boundaries where possible.

We can certainly expose that via the XenBus interface.
> 
> James