From patchwork Thu Oct 4 17:58:39 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ilya Dryomov X-Patchwork-Id: 10626461 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 4D40A16B1 for ; Thu, 4 Oct 2018 17:59:23 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 3E5CA293F2 for ; Thu, 4 Oct 2018 17:59:23 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 31DDB29407; Thu, 4 Oct 2018 17:59:23 +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=-8.0 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI 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 D2E74293F2 for ; Thu, 4 Oct 2018 17:59:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727624AbeJEAxn (ORCPT ); Thu, 4 Oct 2018 20:53:43 -0400 Received: from mail-wm1-f66.google.com ([209.85.128.66]:51504 "EHLO mail-wm1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727407AbeJEAxn (ORCPT ); Thu, 4 Oct 2018 20:53:43 -0400 Received: by mail-wm1-f66.google.com with SMTP id 143-v6so9835863wmf.1 for ; Thu, 04 Oct 2018 10:59:21 -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=0TYrAUVA7oIgmjQfgWNsYoXYBw+SLKieMkHliqYD8VE=; b=ojWEhUO5QyrVhdjQu4nKJO58zvFRg+KYb6LbMfXch5k/qJj/j1+3PC+CqqxnpDNJCt DxeBDuClknO/JkrYxs/7GcMLzyBl0xLTfvcINx0q8aNh6rHOk8LGJGXXOQxVd2Sws4Gx Xoc1ccVaJFSp6IaL+dVFWdd/55d4SPOYPwhX93rB0YtcsDmrX95WMIbxdTQg3i8MnOnF 8fOtoGiZtCfzV9mmLFm2LjK05Oq6Gw2WmVSrvauGp4JfseAhPyeP6ZHRVp8Bn7w44GPd U5IxW7GwfOnDXNmMByStvsTUV+pFVEnBu05pk8M/GRhlLKsk8irhjntNQ031WEJ12BSb L3bg== 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=0TYrAUVA7oIgmjQfgWNsYoXYBw+SLKieMkHliqYD8VE=; b=adY6PCw7CH6zh4CCG4unDyYtY5BRVm8TWaGF67mvA8Iya104BI5OMnR+xuvdnRBIis 0cmt42b7sLewYY2gtMJONQOB+5QsnPj4WRb+p+4wy82wpUwGnh4Zgt+9a3VikFXCWLNi QwAfGzaBpHrNZSAkdtWZfoSDyvFa5DrH9soHmwoCAHpfMI1gewDVYo5v2o41ZF/kaxmj C/oMpHYFJWp2QX2hk1OuzPR6/XE4fhIZHwxHrG/ECtpPopdaZGMRKwHu2KtwQbv2YvDY sKbqldINm6u/5FFkpeaMf0/DA75pSsrhYbpIZtNMv38qTX35b/3iMgs7IoCdnpK1K4/U 4TVw== X-Gm-Message-State: ABuFfohY31+8BmBUWGlBtmhYrurl6bC4FHpy1Fs2Emk1pkWxywjdVVLJ HRkreO/vFCYBOIcMvPvyuUWhMBdP X-Google-Smtp-Source: ACcGV63534uErCjZolo9BaeHsDsVr5HmaDzbNdkqo3Xnc9tA9/EHgL34UgNRAA6BAfLIqfpCnz3Djw== X-Received: by 2002:a1c:1203:: with SMTP id 3-v6mr5440726wms.21.1538675960250; Thu, 04 Oct 2018 10:59:20 -0700 (PDT) Received: from orange.redhat.com ([213.175.37.12]) by smtp.gmail.com with ESMTPSA id z8-v6sm4243888wrp.63.2018.10.04.10.59.19 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 04 Oct 2018 10:59:19 -0700 (PDT) From: Ilya Dryomov To: linux-xfs@vger.kernel.org Cc: Mark Nelson , Eric Sandeen Subject: [PATCH] mkfs.xfs: don't go into multidisk mode if there is only one stripe Date: Thu, 4 Oct 2018 19:58:39 +0200 Message-Id: <20181004175839.18736-1-idryomov@gmail.com> X-Mailer: git-send-email 2.14.4 Sender: linux-xfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-xfs@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP rbd devices report the following geometry: $ blockdev --getss --getpbsz --getiomin --getioopt /dev/rbd0 512 512 4194304 4194304 (4M is unnecessarily high and will probably be made configurable and changed to 64K in the future. By default, the new bluestore backend does double-write for I/Os smaller than 64K.) If pbsz != iomin, mkfs.xfs goes into multidisk mode and, under the assumption that larger multidisk filesystems will have more devices, chooses a higher agcount. Though rbd devices are indeed backed by multiple OSD devices, it appears that high agcount actually degrades the performance with multiple rbd devices on the same host. Commit 9a106b5fbb88 ("mkfs.xfs: Don't stagger AG for a single disk") has set a precedent for treating sunit == swidth specially. Take it one step further. Signed-off-by: Ilya Dryomov --- mkfs/xfs_mkfs.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/mkfs/xfs_mkfs.c b/mkfs/xfs_mkfs.c index 2e53c1e83b6a..c3efa30005a2 100644 --- a/mkfs/xfs_mkfs.c +++ b/mkfs/xfs_mkfs.c @@ -2650,8 +2650,8 @@ _("agsize (%s) not a multiple of fs blk size (%d)\n"), (cfg->dblocks % cfg->agcount != 0); } else { calc_default_ag_geometry(cfg->blocklog, cfg->dblocks, - cfg->dsunit, &cfg->agsize, - &cfg->agcount); + cfg->dsunit != cfg->dswidth, + &cfg->agsize, &cfg->agcount); } }