All of lore.kernel.org
 help / color / mirror / Atom feed
From: Konstantin Shelekhin <k.shelekhin@yadro.com>
To: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: Mike Christie <michael.christie@oracle.com>,
	<target-devel@vger.kernel.org>, <linux-scsi@vger.kernel.org>,
	<linux@yadro.com>, Dmitry Bogdanov <d.bogdanov@yadro.com>
Subject: Re: [PATCH 1/2] scsi: target: core: Add sense reason for space allocation errors
Date: Thu, 21 Oct 2021 11:55:53 +0300	[thread overview]
Message-ID: <YXErGb3f2H4a39cD@yadro.com> (raw)
In-Reply-To: <yq1pmrz6pbl.fsf@ca-mkp.ca.oracle.com>

On Wed, Oct 20, 2021 at 11:21:54PM -0400, Martin K. Petersen wrote:
> 
> Konstantin,
> 
> > According to SBC-3 4.7.3.6 this sense reason shall be used in situations
> > where thin provisioned logical unit cannot satisfy the write request due
> > to the lack of free blocks.
> 
> > +	[TCM_SPACE_ALLOCATION_FAILED] = {
> > +		.key = DATA_PROTECT,
> > +		.asc = 0x27,
> > +		.ascq = 0x07, /* SPACE ALLOCATION FAILED WRITE PROTECT */
> > +	},
> 
> How do we know this is a permanent condition and not a temporary space
> exhaustion?

By permanent condition SBC-3 means that an initiator should not resend
the command immediately as it will fail again. Kernel tries hard not to
fail with BLK_STS_NOSPC:

  /*
   * We're holding onto IO to allow userland time to react.  After the
   * timeout either the pool will have been resized (and thus back in
   * PM_WRITE mode), or we degrade to PM_OUT_OF_DATA_SPACE w/ error_if_no_space.
   */
  static void do_no_space_timeout(struct work_struct *ws)

So BLK_STS_NOSPC means that we are stuck with this condition and some
out-of-scope actions (like running fs-trim on the initiator) are
required.

  reply	other threads:[~2021-10-21  8:56 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-20 18:43 [PATCH 0/2] scsi: target: iblock: Report space allocation errors Konstantin Shelekhin
2021-10-20 18:43 ` [PATCH 1/2] scsi: target: core: Add sense reason for " Konstantin Shelekhin
2021-10-21  3:21   ` Martin K. Petersen
2021-10-21  8:55     ` Konstantin Shelekhin [this message]
2021-10-20 18:43 ` [PATCH 2/2] scsi: target: iblock: Report " Konstantin Shelekhin
2021-10-22  5:27   ` kernel test robot
2021-10-22  5:27     ` kernel test robot
2021-11-08  9:59   ` kernel test robot
2021-11-08  9:59     ` kernel test robot
2021-11-23 13:29   ` kernel test robot
2021-11-23 13:29     ` kernel test robot
2021-11-25  2:36   ` kernel test robot
2021-11-25  2:36     ` kernel test robot
2021-11-25  7:26   ` kernel test robot
2021-11-25  7:26     ` kernel test robot
  -- strict thread matches above, loose matches on Subject: below --
2023-05-17 14:15 [PATCH 0/2] " Konstantin Shelekhin
2023-05-17 14:15 ` [PATCH 1/2] scsi: target: core: Add sense reason for " Konstantin Shelekhin

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=YXErGb3f2H4a39cD@yadro.com \
    --to=k.shelekhin@yadro.com \
    --cc=d.bogdanov@yadro.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=linux@yadro.com \
    --cc=martin.petersen@oracle.com \
    --cc=michael.christie@oracle.com \
    --cc=target-devel@vger.kernel.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.