From patchwork Wed Feb 17 11:16:23 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?UTF-8?q?Javier=20Gonz=C3=A1lez?= X-Patchwork-Id: 8336721 Return-Path: X-Original-To: patchwork-linux-block@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 189429F2F0 for ; Wed, 17 Feb 2016 11:16:42 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 301D620376 for ; Wed, 17 Feb 2016 11:16:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 3A3942037C for ; Wed, 17 Feb 2016 11:16:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1161224AbcBQLQj (ORCPT ); Wed, 17 Feb 2016 06:16:39 -0500 Received: from mail-wm0-f49.google.com ([74.125.82.49]:34108 "EHLO mail-wm0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1161184AbcBQLQi (ORCPT ); Wed, 17 Feb 2016 06:16:38 -0500 Received: by mail-wm0-f49.google.com with SMTP id b205so150822395wmb.1 for ; Wed, 17 Feb 2016 03:16:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lightnvm-io.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:mime-version:content-type :content-transfer-encoding; bh=UFysOkEZv83QrXWEcqAZ36DY9sbuRp2thbsSypIHp7o=; b=KIT0eK535CEqE2jmQ0js5w+gGkBrg0uRyC/2ttPn+kbcdHK7S34CNG3sHZPegVtWgD 1dJ3VCPBNkN9JJCHFaPdbqCGM/oNRhxtxOEOkvTQIZqG1TfDYXjwOMPNntPhixbKmoRQ RKQ1g8Widt4F1BX8N4btrcqBiuHnFAsTLCy7b/cgYRqG4qgw9i7bkSCSELFuARc41E2w hBSiYXwg/D1aDla4+6a2EdUAQwFBKM8C52BcRzPzmQXvLtozsU/LUAJxI20bbvsscXQa lEr7SXWRZXUHuH9Nx+XlK3Cux/JliKJKtnJpQsIacj+oz/+ZZ22jde3wtK5hZA3IJVuB L1MQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-type:content-transfer-encoding; bh=UFysOkEZv83QrXWEcqAZ36DY9sbuRp2thbsSypIHp7o=; b=MobTDBWlg2mdzJJo0VsHoJscDrjyQLuWYpPA4asnN0KyZYldV31QaJzBcxaEq49mOM 8vsFQ+S3tax3gCEkwLabjtzjGyloc4QxCOX5f8/cs9Ec0gUfbtwhCpvaYwXzxqR7X3Vy jOFWfDKI/5Ol+piqtdcARjCVX2viwmwa7TmkzJtnzTbrMAYqbJ2p9OdQZZREZfy62vyY aG1TESBI0t3UAKcD4M2tl86PIdL0/ZlK7Mu8/MGPO96Dc0LF3I1vgIoZF/2BcS18QfrC 2XUw11oHV1AiJtvhtOC6WwyZFq7/TTwdCBoQCzCKqC9BCGSF6NxyG0iaXD2jh89HjB1u oFkA== X-Gm-Message-State: AG10YOSfcTChoG4nJDAxY1xAfA2BLdDfM76DJDzh9dsrAwsJ3Siy2FoNZhP9LlvF12Mqew== X-Received: by 10.28.238.144 with SMTP id j16mr2853748wmi.43.1455707797490; Wed, 17 Feb 2016 03:16:37 -0800 (PST) Received: from localhost.localdomain (6164198-cl69.boa.fiberby.dk. [193.106.164.198]) by smtp.gmail.com with ESMTPSA id c26sm24925851wmi.24.2016.02.17.03.16.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 17 Feb 2016 03:16:36 -0800 (PST) From: "=?UTF-8?q?Javier=20Gonz=C3=A1lez?=" X-Google-Original-From: =?UTF-8?q?Javier=20Gonz=C3=A1lez?= To: mb@lightnvm.io Cc: linux-kernel@vger.kernel.org, linux-block@vger.kernel.org, =?UTF-8?q?Javier=20Gonz=C3=A1lez?= Subject: [PATCH] lightnvm: do not reserve lun on l2p loading Date: Wed, 17 Feb 2016 12:16:23 +0100 Message-Id: <1455707783-31789-1-git-send-email-javier@javigon.com> X-Mailer: git-send-email 2.1.4 MIME-Version: 1.0 Sender: linux-block-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,T_DKIM_INVALID,UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP When the l2p table is loaded, addresses are checked for the lun they belong to and luns are reserved accordingly. This assumes that metadata is being stored in the backend device to recover the previous target configuration. Since this is not yet implemented, this check collides with some of the core initialization (e.g., sysblock initialization when a page is formed by several sectors). We take this check out and for now rely on that the right target will be created instead. When metadata is stored to recover a target, this check will come natural as aprt of the recovery strategy. FIXES c87ea75 Signed-off-by: Javier González --- drivers/lightnvm/gennvm.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/lightnvm/gennvm.c b/drivers/lightnvm/gennvm.c index b97801c..42c1c2a 100644 --- a/drivers/lightnvm/gennvm.c +++ b/drivers/lightnvm/gennvm.c @@ -192,9 +192,6 @@ static int gennvm_block_map(u64 slba, u32 nlb, __le64 *entries, void *private) lun_id = div_u64(pba, dev->sec_per_lun); lun = &gn->luns[lun_id]; - if (!test_bit(lun_id, dev->lun_map)) - __set_bit(lun_id, dev->lun_map); - /* Calculate block offset into lun */ pba = pba - (dev->sec_per_lun * lun_id); blk = &lun->vlun.blocks[div_u64(pba, dev->sec_per_blk)];