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.
