From patchwork Tue May 23 15:08:27 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ilya Dryomov X-Patchwork-Id: 9742953 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 5AB5560380 for ; Tue, 23 May 2017 15:08:40 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 4D0A928684 for ; Tue, 23 May 2017 15:08:40 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 4198A28773; Tue, 23 May 2017 15:08:40 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.3 required=2.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_HI, RCVD_IN_SORBS_SPAM, T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id DEE5428684 for ; Tue, 23 May 2017 15:08:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1763376AbdEWPIh (ORCPT ); Tue, 23 May 2017 11:08:37 -0400 Received: from mail-qk0-f195.google.com ([209.85.220.195]:33458 "EHLO mail-qk0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1760007AbdEWPIh (ORCPT ); Tue, 23 May 2017 11:08:37 -0400 Received: by mail-qk0-f195.google.com with SMTP id o85so23145320qkh.0 for ; Tue, 23 May 2017 08:08:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id; bh=Pi4qPo/nUvMOYc2vfx90mI7vispCrX657wp3j+aEYmQ=; b=YRUaHdDhCK4w9DtBqzdbuow52xO4RclgHxoAq5NKDWmSW5qz4mV0pLAlqY4HZvQAIP GvWNMdg8V1vLVvqiBRTv1/vZU9XsiIzRjZs9eAv+hKqVkWpl32pXclLM1MQ8sbkIKlBl mSYl4oLekr+FHbltu/5EYJgi02qwS0oSqEiFyJRavjUfm8AiUMFRgcJzuFfdf79NiEs5 MnYNFeGOpjs1WPBnAe5Qv8deDbZucHCYXREdG2+Xiy3zaiZxmo+iJvvLJfXwvS66EghO 90NAyx34ghSdWaemXJPCrlbR+gAIaK8zbRJW4mC01iDvnUUoKGq6kiP4pU9CWFZ6cPDf gaNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=Pi4qPo/nUvMOYc2vfx90mI7vispCrX657wp3j+aEYmQ=; b=hYVvSoFpti1EhzGeYOPSFVR6CE317xYWYmcnBpMru+4JVk90VE3a4f0/FNYPs//tys cUkBYSQw0T9agIdaPy1memquCrkRZcA8+21KuJnF8FWy3ZU9/rffZ/o98TYG6xxernyb g6PmDBYBTBs8vXRdhPFBjXq7p/mILyVS8ifSrGSgixa5ZfSkDKUcB5M2R/zp3rE2ivQ8 4IlOXEfrgXr1d1kcy4FHRdvO0wrPGupPzettUr2OP6bVZdUYgh1LUFxt2IV9xuBrE37F brn7m2ol4Gcf3jOsUuNIqCKiG6grQ1VOecsqVLUExjclp3vuc+r9X4AgLN9ujepNCiIZ RZUA== X-Gm-Message-State: AODbwcAPP9EEj3PP5e+/zAhePqOPzystsCiYyMOWdKk3LoasADUuGLYM sZrdsM6CTQldfA== X-Received: by 10.233.232.213 with SMTP id a204mr26719819qkg.173.1495552116049; Tue, 23 May 2017 08:08:36 -0700 (PDT) Received: from orange.brq.redhat.com. (nat-pool-brq-t.redhat.com. [213.175.37.10]) by smtp.gmail.com with ESMTPSA id c18sm610008qkg.32.2017.05.23.08.08.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 May 2017 08:08:35 -0700 (PDT) From: Ilya Dryomov To: ceph-devel@vger.kernel.org Cc: Christoph Hellwig , Hannes Reinecke Subject: [PATCH] rbd: implement REQ_OP_WRITE_ZEROES Date: Tue, 23 May 2017 17:08:27 +0200 Message-Id: <1495552107-1237-1-git-send-email-idryomov@gmail.com> X-Mailer: git-send-email 2.4.3 Sender: ceph-devel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: ceph-devel@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Commit 93c1defedcae ("rbd: remove the discard_zeroes_data flag") explicitly didn't implement REQ_OP_WRITE_ZEROES for rbd, while the following commit 48920ff2a5a9 ("block: remove the discard_zeroes_data flag") dropped ->discard_zeroes_data in favor of REQ_OP_WRITE_ZEROES. rbd does support efficient zeroing via CEPH_OSD_OP_ZERO opcode and will release either some or all blocks depending on whether the zeroing request is rbd_obj_bytes() aligned. This is how we currently implement discards, so REQ_OP_WRITE_ZEROES can be identical to REQ_OP_DISCARD for now. Caveats: - REQ_NOUNMAP is ignored, but AFAICT that's true of at least two other current implementations - nvme and loop - there is no ->write_zeroes_alignment and blk_bio_write_zeroes_split() is hence less helpful than blk_bio_discard_split(), but this can (and should) be fixed on the rbd side In the future we will split these into two code paths to respect REQ_NOUNMAP on zeroout and save on zeroing blocks that couldn't be released on discard. Fixes: 93c1defedcae ("rbd: remove the discard_zeroes_data flag") Signed-off-by: Ilya Dryomov Reviewed-by: Jason Dillaman Reviewed-by: Jason Dillaman Reviewed-by: Christoph Hellwig --- drivers/block/rbd.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/block/rbd.c b/drivers/block/rbd.c index 454bf9c34882..c16f74547804 100644 --- a/drivers/block/rbd.c +++ b/drivers/block/rbd.c @@ -4023,6 +4023,7 @@ static void rbd_queue_workfn(struct work_struct *work) switch (req_op(rq)) { case REQ_OP_DISCARD: + case REQ_OP_WRITE_ZEROES: op_type = OBJ_OP_DISCARD; break; case REQ_OP_WRITE: @@ -4420,6 +4421,7 @@ static int rbd_init_disk(struct rbd_device *rbd_dev) q->limits.discard_granularity = segment_size; q->limits.discard_alignment = segment_size; blk_queue_max_discard_sectors(q, segment_size / SECTOR_SIZE); + blk_queue_max_write_zeroes_sectors(q, segment_size / SECTOR_SIZE); if (!ceph_test_opt(rbd_dev->rbd_client->client, NOCRC)) q->backing_dev_info->capabilities |= BDI_CAP_STABLE_WRITES;