Re: [BUG] blkback reporting incorrect number of sectors, unable to boot

[Mike Reardon <mule@inso.org>]

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

So am I correct in reading this that for at least the foreseeable future
storage using 4k sector sizes is not gonna happen?  I'm just trying to
figure out if I need to get some different hardware.

Thank you!

On Tue, Nov 7, 2017 at 5:41 AM, Roger Pau Monné <roger.pau@citrix.com>
wrote:

> On Tue, Nov 07, 2017 at 04:31:06AM -0700, Jan Beulich wrote:
> > >>> On 07.11.17 at 11:30, <roger.pau@citrix.com> wrote:
> > > On Mon, Nov 06, 2017 at 05:33:37AM -0700, Jan Beulich wrote:
> > >> >>> On 04.11.17 at 05:48, <mule@inso.org> wrote:
> > >> > I added some additional storage to my server with some native 4k
> sector
> > >> > size disks.  The LVM volumes on that array seem to work fine when
> mounted
> > >> > by the host, and when passed through to any of the Linux guests, but
> > >> > Windows guests aren't able to use them when using PV drivers.  The
> work
> > >> > fine to install when I first install Windows (Windows 10, latest
> build) but
> > >> > once I install the PV drivers it will no longer boot and give an
> > >> > inaccessible boot device error.  If I assign the storage to a
> different
> > >> > Windows guest that already has the drivers installed (as secondary
> storage,
> > >> > not as the boot device) I see the disk listed in disk management,
> but the
> > >> > size of the disk is 8x larger than it should be.  After looking
> into it a
> > >> > bit, the disk is reporting 8x the number of sectors it should have
> when I
> > >> > run xenstore-ls.  Here is the info from xenstore-ls for the
> relevant volume:
> > >> >
> > >> >       51712 = ""
> > >> >        frontend = "/local/domain/8/device/vbd/51712"
> > >> >        params = "/dev/tv_storage/main-storage"
> > >> >        script = "/etc/xen/scripts/block"
> > >> >        frontend-id = "8"
> > >> >        online = "1"
> > >> >        removable = "0"
> > >> >        bootable = "1"
> > >> >        state = "2"
> > >> >        dev = "xvda"
> > >> >        type = "phy"
> > >> >        mode = "w"
> > >> >        device-type = "disk"
> > >> >        discard-enable = "1"
> > >> >        feature-max-indirect-segments = "256"
> > >> >        multi-queue-max-queues = "12"
> > >> >        max-ring-page-order = "4"
> > >> >        physical-device = "fe:0"
> > >> >        physical-device-path = "/dev/dm-0"
> > >> >        hotplug-status = "connected"
> > >> >        feature-flush-cache = "1"
> > >> >        feature-discard = "0"
> > >> >        feature-barrier = "1"
> > >> >        feature-persistent = "1"
> > >> >        sectors = "34359738368"
> > >> >        info = "0"
> > >> >        sector-size = "4096"
> > >> >        physical-sector-size = "4096"
> > >> >
> > >> >
> > >> > Here are the numbers for the volume as reported by fdisk:
> > >> >
> > >> > Disk /dev/tv_storage/main-storage: 16 TiB, 17592186044416 bytes,
> 4294967296
> > >> > sectors
> > >> > Units: sectors of 1 * 4096 = 4096 bytes
> > >> > Sector size (logical/physical): 4096 bytes / 4096 bytes
> > >> > I/O size (minimum/optimal): 4096 bytes / 4096 bytes
> > >> > Disklabel type: dos
> > >> > Disk identifier: 0x00000000
> > >> >
> > >> > Device                        Boot Start        End    Sectors Size
> Id Type
> > >> > /dev/tv_storage/main-storage1          1 4294967295 4294967295  16T
> ee GPT
> > >> >
> > >> >
> > >> > As with the size reported in Windows disk management, the number of
> sectors
> > >> > from xenstore seems is 8x higher than what it should be.  The disks
> aren't
> > >> > using 512b sector emulation, they are natively 4k, so I have no
> idea where
> > >> > the 8x increase is coming from.
> > >>
> > >> Hmm, looks like a backend problem indeed: struct hd_struct's
> > >> nr_sects (which get_capacity() returns) looks to be in 512-byte
> > >> units, regardless of actual sector size. Hence the plain
> > >> get_capacity() use as well the (wrongly open coded) use of
> > >> part_nr_sects_read() looks insufficient in vbd_sz(). Roger,
> > >> Konrad?
> > >
> > > Hm, AFAICT sector-size should always be set to 512.
> >
> > Which would mean that bdev_logical_block_size() can't be used by
> > blkback to set this value. Yet then - what's the point of the xenstore
> > setting if it's always the same value anyway?
>
> Some frontends (at least FreeBSD) will choke if sector-size is not
> set. So we have the following scenario:
>
>  - Windows: acknowledges sector-size * sectors in order to set disk
>    capacity.
>  - Linux: sets disk capacity to sectors * 512.
>  - FreeBSD: sets disk capacity to sector-size * sectors, will choke if
>    sector-size is not set.
>
> In order to keep compatibility with all of them AFAICT the only option
> is to hardcode sector-size to 512 in xenstore.
>
> Roger.
>

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

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

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