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: Wed, 15 May 2013 12:10:44 +0200 Message-ID: <51935F24.3020105@canonical.com> References: <5191272A.7070703@canonical.com> <51920C4B02000078000D5D9F@nat28.tlf.novell.com> <519354C1.9010705@canonical.com> <519375BC02000078000D6571@nat28.tlf.novell.com> <6035A0D088A63A46850C3988ED045A4B57B51BBE@BITCOM1.int.sbss.com.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7044937212349139837==" Return-path: In-Reply-To: <6035A0D088A63A46850C3988ED045A4B57B51BBE@BITCOM1.int.sbss.com.au> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: James Harper Cc: Konrad Rzeszutek Wilk , "roger.pau@citrix.com" , Jan Beulich , xen-devel List-Id: xen-devel@lists.xenproject.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============7044937212349139837== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigB875C73E4666B356FE6CC315" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB875C73E4666B356FE6CC315 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 15.05.2013 12:04, James Harper wrote: >>=20 >>>>> On 15.05.13 at 11:26, Stefan Bader >> wrote: >>> On 14.05.2013 10:04, Jan Beulich wrote: >>>>>>> On 13.05.13 at 19:47, Stefan Bader >> wrote: >>>>> --- a/drivers/block/xen-blkback/xenbus.c +++ >>>>> b/drivers/block/xen-blkback/xenbus.c @@ -704,6 +704,13 @@ again:=20 >>>>> dev->nodename); goto abort; } + err =3D xenbus_printf(xbt, >>>>> dev->nodename, "physical-sector-size", >> "%u", >>>>> + bdev_physical_block_size(be->blkif->vbd.bdev)); + if (err) = {=20 >>>>> + xenbus_dev_fatal(dev, err, "writing %s/physical-sector-size", + >>>>> dev->nodename); + goto abort; >>>>=20 >>>> Failure here should not be fatal (as with any other protocol=20 >>>> extensions). >>>=20 >>> So I suppose that should be xenbus_dev_error and no abort here. Just = >>> wondering (and sorry for being thick headed here) why would a failure= >>> here be different in severity for an extension or not. Is that not ju= st >>> adding an element to the xenstore object and failure would not be rel= ated >>> to this being an >> extension? >>=20 >> A driver should only bail upon encountering a problem that it can't re= cover >> from. Failure to write a xenstore node that neither the backend nor th= e >> frontend really require for their work is certainly not among those. Y= es, >> it's only a xenstore write, but it can fail at least theoretically (or= else >> there wouldn't be a need for error handling here in the first place), = and >> you shouldn't handle such failure in undue ways (i.e. failure to write= >> required nodes is fatal, but failure to write nodes related to extensi= ons >> isn't). >>=20 >=20 > What is the recovery though? If the physical block size is unusual (eg = not > 512) and the write has failed, what is the outcome? I suspect that it's= going > to not be what the user expected - partitions could be incorrectly alig= ned if > doing an install, etc. If it were my system then in the (vanishingly ra= re?) > case that this write failed, I'd prefer a hard failure. If the write fails the frontend just behaves as today and you may get the= wrong alignment. It is not a fatal error, the access to the device will be poss= ible in all variations. Just performance may be unexpectedly poor. >=20 > If a simple write to xenstore fails then isn't the world coming to an e= nd > anyway? Probably true. And I wonder whether its moot one way or the other as prob= ably those cases where this write would fail, it would have failed before and = one doe not get there at all. >=20 > James >=20 --------------enigB875C73E4666B356FE6CC315 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/ iQIcBAEBCgAGBQJRk18kAAoJEOhnXe7L7s6jVpkQAI6bPw3Guwrw7FuEfcGnz2Tf 9N3E08nahNQ2SCgRBE8+zmm6/PizJqREy1RPkMTvQPhzkXwwqrwgxW9KwsvS2jyi SlLBIZyn3SSn8B583pGn6DRT4n6NFyatG/9kEBDeivOLnu/wPH0fWhSpr1HfDMoc eXbyR4bw+8LA+mo2CAkgLF/srvq1iURjjhgda3F0ICoBNPvPtpismt94ea7YOMla VcDmjSc7ztF0aCiQokI7toWS44u9wNQUVox95agnUHUBC5keiFUcv87S8k9p8RKx RtWUBlDJ8Djl0mwMOzetaHEZdxhCH02pt7CapaoaMI8cWX8705VghVD+CnyjZjSq hMPKwHpuNCM4DwIz5solGsa9eqMKy+Xm7tR7Z4sS2q3NZjPUkZLuE7QIl9//C6bV 5ObMxNCI0Qc6dq1uhWAXEb8aKQDwtMT0ZRw/z7BYYJqlCfqRQ4kqcNacgReAkmVl dv8hWRGrI4qXGXBm1oeocO6zdY8Ov10CRIkPYW16zy0nCJSebqt1TG6DcFrCdTHG vS3rGFctflDBGdKcueoxmvmZillX97WUZd84R2eDqImqAm6a+rbwSJgkzQ+YNpi0 J0E9SLOqoaZq7kp57Jt2ioEj1+ymFTzvEA3uX2SgtOm4/uFKkk+ycCru7VVjYOC8 6z4j/21aq7zQz8A57Xxw =TOEN -----END PGP SIGNATURE----- --------------enigB875C73E4666B356FE6CC315-- --===============7044937212349139837== 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 --===============7044937212349139837==--