|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] xen-blk(front|back): Handle large physical sector disks
On 14.05.2013 16:49, Roger Pau Monné wrote: > 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 Thanks, I will re-spin/-send the patch soonish. > just have one question, if for example we are using iscsi disks, do > different initiators report different physical sector sizes for the same > disk? Personally I have not yet used an iscsi setup, yet. But if it is the same physical disk used by the target, the initiators should report the same sizes. An interesting case would be stacks that combine multiple disks. But that is another thing. But would the usual iscsi setup not rather be to have the guest directly talk to the target? Thus not using blkfront at all? > > 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. Initially I was wondering whether this needs to support cases where a guest is saved, and then this dump and the contents of a disk were transfered (ending up on a different physical disk). But that if probably just crazy, impossible or both. > > _______________________________________________ > Xen-devel mailing list > Xen-devel@xxxxxxxxxxxxx > http://lists.xen.org/xen-devel > Attachment:
signature.asc _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |