Re: [Xen-devel] [PATCH] xen-blk(front|back): Handle large physical sector disks

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On 13/05/13 19:47, Stefan Bader wrote:
> I accidentally realized today that any domU's using the paravirt disk driver
> potentially suffer from poor performance when they get handed in a physical
> volume and partitioning is done inside the guest. The physical volume passed 
> in
> has to be one that has the compat 512 logical sector size but hints its real
> sector size (eg. 4096) as physical sector size.
> 
> In dom0 handling is correct and partitions or logical volumes there would be
> aligned to 4k. But the blkfront driver just gets one sector size (the logical)
> passed in from netback. And so inside the guest the drive appears to be an old
> style 512/512 drive. Alignment of partitions created in the guest very likely 
> go
> wrong somewhere (they do for me).
> 
> I tried to fix this in a way that works with all four combinations of dom0 and
> domU drivers. Tested those with a PVM guest that was set up to have a logical
> volume passed in as xvdb). Sidenote: PVM guests that map files or volume
> directly to partitions may be accidentally ok as ext4 uses 4k blocks by 
> default).
> 
> What I am not sure about is whether this also is sufficient for handling
> migration (possible to another host with other sectors). But I think that the
> units of tables is still 512, only alignment is changed. So it should more or
> less work.
> 
> How does this look to you?

Thanks for the patch, apart from Jan's comment, it looks good to me. I
just have one question, if for example we are using iscsi disks, do
different initiators report different physical sector sizes for the same
disk?

I'm asking this because AFAICS blk_queue_physical_block_size will only
be set when the disk is first attached, but not when recovering from
migration, and if different initiators report different physical sector
sizes we should probably call blk_queue_physical_block_size with the new
value when recovering from migration.

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