From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Bader Subject: Re: [PATCH] xen-blk(front|back): Handle large physical sector disks Date: Tue, 14 May 2013 18:11:42 +0200 Message-ID: <5192623E.3080806@canonical.com> References: <5191272A.7070703@canonical.com> <51924F0C.3080006@citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2355364160649334179==" Return-path: In-Reply-To: <51924F0C.3080006@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= Cc: "xen-devel@lists.xensource.com" , Konrad Rzeszutek Wilk List-Id: xen-devel@lists.xenproject.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============2355364160649334179== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig06CE3749F288C77ACD6C22FF" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig06CE3749F288C77ACD6C22FF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 14.05.2013 16:49, Roger Pau Monn=E9 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 phy= sical >> 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 it= s real >> sector size (eg. 4096) as physical sector size. >> >> In dom0 handling is correct and partitions or logical volumes there wo= uld 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 b= e 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 volu= me >> directly to partitions may be accidentally ok as ext4 uses 4k blocks b= y default). >> >> What I am not sure about is whether this also is sufficient for handli= ng >> migration (possible to another host with other sectors). But I think t= hat the >> units of tables is still 512, only alignment is changed. So it should = more or >> less work. >> >> How does this look to you? >=20 > 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 sam= e > 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 s= izes. 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? >=20 > 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 ne= w > value when recovering from migration. Initially I was wondering whether this needs to support cases where a gue= st is saved, and then this dump and the contents of a disk were transfered (end= ing up on a different physical disk). But that if probably just crazy, impossibl= e or both. >=20 > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel >=20 --------------enig06CE3749F288C77ACD6C22FF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBCgAGBQJRkmJKAAoJEOhnXe7L7s6jwZkP/3dfxdCUFP8sQA28xWoeNtof ZRv7EVpoX24HtaPX8rJQeV6n0UjIJWtSwGAvK5gESq7dhYfraAqZduFCItbiPhf0 clU1jtkSgZEgZ9e7m8w4R9wxDKwhPU+BfxW3yqzPXKdFlp+T8IKSXSezOaTp5a/J +w6bpaFsz7iszE/Gjyg2TNcqH0kQsS1oFmawhJiphYZD18uLIm54BBqEG0N4+7Zh XSfSYenWZQNPZUxQhNW4IXHP1tEe5VR5jbGCDiiGgH+L81k6bPdrmHRg5D0xmJVr EnhX2Wgh3vWLrojXwitt07D22R3lo2lVlS50ko5VmhKXaELWaGzMkdlSXhMTfqP4 AJLghhYDmz+7YqNCrAbKPy4KlLjJMM35cfmmztwOBeB1Iot8cFjkzdiFbo1JaV3d LRcmH0EQKwjPUaXLbljG1J+SzmGDqJFEjpxcpvNlSCbb4h0t0nAxaEVscO6jbiah LQt87KA/PALK06HnWB7FX5jrV6td382pDvOyNKYYNkrZSzJEGYGWnIuCYVAhLUlE E4PqWZqmsavEl9s+fBRMQMe6A799iarl9K68Vn26jUlla1TX5JGEYf2QsOU5NkH2 gItkarU2T2Im/YqMwmgfp8xd9q8CWeYP48LCyumav35OxokLhSzR7HhJgRG4932G MyYgrqYP++8yzUpB8t1j =blHj -----END PGP SIGNATURE----- --------------enig06CE3749F288C77ACD6C22FF-- --===============2355364160649334179== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============2355364160649334179==--