From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 11582C0015E for ; Tue, 15 Aug 2023 08:09:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232758AbjHOIIi (ORCPT ); Tue, 15 Aug 2023 04:08:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59432 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234493AbjHOIIV (ORCPT ); Tue, 15 Aug 2023 04:08:21 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 51AAA10D8 for ; Tue, 15 Aug 2023 01:08:20 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id D533762584 for ; Tue, 15 Aug 2023 08:08:19 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1CF03C433C7 for ; Tue, 15 Aug 2023 08:08:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1692086899; bh=tYR/mWt9+XcWnjEIZC34o/6dbrO1fAJ530t13e/uy4k=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=KldN/6DqgLk2Om0CZk6crO9Y16bXTTU46U9dY1OIYJzfA49ozgiSbi/H++z5dRvfh Mc3lmHab1wGG8LbKwwi4lvhVGUQqSKzS0arr2bvz+B2gu5EHRvHAsEYTIioBv2W3C9 KBNVk3q5F6UF46mUwNcOlU9LTF+BJ3msuu1dAYrjDwC9fZUO/KrnxpDbor3jdj40tP GsUTPDXAjrozGLGyopPWBWesTJguvvHm6wL4df1nkXeQWN0PPqIa4oWJZFOHaxLELW 5+by7DfS+55JGdktlhAtvrXQUxzifPGi2qz3+FaEFV8qiD7z+aeThQai0Mae12kQcZ XXUFgrGQ0p+zA== Received: by mail-lf1-f53.google.com with SMTP id 2adb3069b0e04-4fe3b86cec1so8017882e87.2 for ; Tue, 15 Aug 2023 01:08:19 -0700 (PDT) X-Gm-Message-State: AOJu0Yyd7xaMqAXhTp6LIDbcPz0mhbj7u08bjw0HxogbaJBjv6WuJDmn Iaps04pBY9TAwUTKHOZrwcgl415l15wFrO6srH0= X-Google-Smtp-Source: AGHT+IGEt/gwOFDZm3nxEVOQbrI/2gKuSy6cb2mpTGwpr6Jg647YCh47UEG2gT9IHLDznvIQCetBs2P/crkBQznEr0c= X-Received: by 2002:a19:5f05:0:b0:4f8:6d99:f4f3 with SMTP id t5-20020a195f05000000b004f86d99f4f3mr6256121lfb.52.1692086897097; Tue, 15 Aug 2023 01:08:17 -0700 (PDT) MIME-Version: 1.0 References: <20230814205347.17891-1-djeffery@redhat.com> In-Reply-To: <20230814205347.17891-1-djeffery@redhat.com> From: Song Liu Date: Tue, 15 Aug 2023 16:08:04 +0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH RESEND] md: raid0: account for split bio in iostat accounting To: David Jeffery Cc: linux-raid@vger.kernel.org, Laurence Oberman , Yu Kuai Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-raid@vger.kernel.org On Tue, Aug 15, 2023 at 4:54=E2=80=AFAM David Jeffery = wrote: > > When a bio is split by md raid0, the newly created bio will not be tracke= d > by md for I/O accounting. Only the portion of I/O still assigned to the > original bio which was reduced by the split will be accounted for. This > results in md iostat data sometimes showing I/O values far below the actu= al > amount of data being sent through md. > > md_account_bio() needs to be called for all bio generated by the bio spli= t. > > Fixes: 10764815ff47 ("md: add io accounting for raid0 and raid5") > Signed-off-by: David Jeffery > Tested-by: Laurence Oberman > Reviewed-by: Laurence Oberman > Reviewed-by: Yu Kuai It appears this patch conflicts with Jan's set: https://lore.kernel.org/linux-raid/20230814091452.9670-1-jack@suse.cz/ Please rebase on top of md-next and resubmit the patch: https://git.kernel.org/pub/scm/linux/kernel/git/song/md.git/log/?h=3Dmd-nex= t > --- > > No change to the patch itself. Added Fixes and Reviewed-by lines. > > A simple example of the issue was generated using a raid0 device on parti= tions > to the same device. Since all raid0 I/O then goes to one device, it makes= it > easy to see a gap between the md device and its sd storage. Reading an lv= m > device on top of the md device, the iostat output (some 0 columns and ext= ra > devices removed to make the data more compact) was: > > Device tps kB_read/s kB_wrtn/s kB_dscd/s kB_read > md2 0.00 0.00 0.00 0.00 0 > sde 0.00 0.00 0.00 0.00 0 > md2 1364.00 411496.00 0.00 0.00 411496 > sde 1734.00 646144.00 0.00 0.00 646144 > md2 1699.00 510680.00 0.00 0.00 510680 > sde 2155.00 802784.00 0.00 0.00 802784 > md2 803.00 241480.00 0.00 0.00 241480 > sde 1016.00 377888.00 0.00 0.00 377888 > md2 0.00 0.00 0.00 0.00 0 > sde 0.00 0.00 0.00 0.00 0 > > I/O was generated doing large direct I/O reads (12M) with dd to a linear > lvm volume on top of the 4 leg raid0 device. > > The md2 reads were showing as roughly 2/3 of the reads to the sde device > containing all of md2's raid partitions. The sum of reads to sde was > 1826816 kB, which was the expected amount as it was the amount read by > dd. With the patch, the total reads from md will match the reads from > sde and be consistent with the amount of I/O generated. We can include this part in the commit log to keep more context for future reference. Thanks, Song