All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Bader <stefan.bader@canonical.com>
To: James Harper <james.harper@bendigoit.com.au>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"roger.pau@citrix.com" <roger.pau@citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [PATCH] xen-blk(front|back): Handle large physical sector disks
Date: Wed, 15 May 2013 12:10:44 +0200	[thread overview]
Message-ID: <51935F24.3020105@canonical.com> (raw)
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B57B51BBE@BITCOM1.int.sbss.com.au>


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

On 15.05.2013 12:04, James Harper wrote:
>> 
>>>>> On 15.05.13 at 11:26, Stefan Bader <stefan.bader@canonical.com>
>> wrote:
>>> On 14.05.2013 10:04, Jan Beulich wrote:
>>>>>>> On 13.05.13 at 19:47, Stefan Bader <stefan.bader@canonical.com>
>> wrote:
>>>>> --- a/drivers/block/xen-blkback/xenbus.c +++
>>>>> b/drivers/block/xen-blkback/xenbus.c @@ -704,6 +704,13 @@ again: 
>>>>> dev->nodename); goto abort; } +	err = xenbus_printf(xbt,
>>>>> dev->nodename, "physical-sector-size",
>> "%u",
>>>>> +			    bdev_physical_block_size(be->blkif->vbd.bdev)); +	if (err) { 
>>>>> +		xenbus_dev_fatal(dev, err, "writing %s/physical-sector-size", +
>>>>> dev->nodename); +		goto abort;
>>>> 
>>>> Failure here should not be fatal (as with any other protocol 
>>>> extensions).
>>> 
>>> 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 just
>>> adding an element to the xenstore object and failure would not be related
>>> to this being an
>> extension?
>> 
>> A driver should only bail upon encountering a problem that it can't recover
>> from. Failure to write a xenstore node that neither the backend nor the
>> frontend really require for their work is certainly not among those. Yes,
>> 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 extensions
>> isn't).
>> 
> 
> 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 aligned if
> doing an install, etc. If it were my system then in the (vanishingly rare?)
> 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 possible in
all variations. Just performance may be unexpectedly poor.

> 
> If a simple write to xenstore fails then isn't the world coming to an end
> anyway?

Probably true. And I wonder whether its moot one way or the other as probably
those cases where this write would fail, it would have failed before and one doe
not get there at all.

> 
> James
> 



[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]

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

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

  reply	other threads:[~2013-05-15 10:10 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-13 17:47 [PATCH] xen-blk(front|back): Handle large physical sector disks Stefan Bader
2013-05-14  8:04 ` Jan Beulich
2013-05-15  9:26   ` Stefan Bader
2013-05-15  9:47     ` Jan Beulich
2013-05-15 10:04       ` James Harper
2013-05-15 10:10         ` Stefan Bader [this message]
2013-05-15 12:23         ` Jan Beulich
2013-05-15 13:54     ` Konrad Rzeszutek Wilk
2013-05-15 10:58   ` Stefan Bader
2013-05-15 12:28     ` Jan Beulich
2013-05-14 14:49 ` Roger Pau Monné
2013-05-14 16:11   ` Stefan Bader
2013-05-15 15:02 ` [PATCH v3] " Stefan Bader
2013-05-22 11:48   ` Stefan Bader
2013-05-22 12:21     ` Jan Beulich
2013-05-22 13:15       ` Stefan Bader
2013-05-22 13:22         ` Jan Beulich
2013-05-22 13:02     ` Konrad Rzeszutek Wilk
2013-05-28 12:47   ` Konrad Rzeszutek Wilk
2013-05-28 12:55     ` Stefan Bader
2013-05-28 16:17       ` Konrad Rzeszutek Wilk
2013-05-28 18:03         ` Stefan Bader
2013-06-05 20:25           ` Konrad Rzeszutek Wilk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51935F24.3020105@canonical.com \
    --to=stefan.bader@canonical.com \
    --cc=JBeulich@suse.com \
    --cc=james.harper@bendigoit.com.au \
    --cc=konrad.wilk@oracle.com \
    --cc=roger.pau@citrix.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.