> On 22 Mar 2019, at 22.48, Igor Konopko <igor.j.konopko@xxxxxxxxx> wrote:
>
> Emeta does not have corresponding OOB metadata mapping valid, so there
> is no need to try to recover L2P mapping from it.
>
> Signed-off-by: Igor Konopko <igor.j.konopko@xxxxxxxxx>
> ---
> drivers/lightnvm/pblk-recovery.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/lightnvm/pblk-recovery.c b/drivers/lightnvm/pblk-recovery.c
> index 4e8f382..74e5b17 100644
> --- a/drivers/lightnvm/pblk-recovery.c
> +++ b/drivers/lightnvm/pblk-recovery.c
> @@ -479,6 +479,15 @@ static int pblk_recov_scan_oob(struct pblk *pblk, struct pblk_line *line,
> goto retry_rq;
> }
>
> + if (paddr >= line->emeta_ssec) {
> + /*
> + * We reach emeta region and we don't want
> + * to recover oob from emeta region.
> + */
> + bio_put(bio);
> + goto completed;
> + }
> +
>
This recovery path is supposed to be a last resource to recover an open
line. Since emeta_ssec is calculated based on the new state after
recovery, it is not guaranteed that the bad blocks are the same as when
the last pblk instance was interrupted. Thus, emeta_ssec is not to be
trusted.
I would rather do the full scan at this point.
Javier
Attachment:
signature.asc
Description: Message signed with OpenPGP
