[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] bug when using 4K sectors?
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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |