Received: by 2002:a05:7412:bbc7:b0:fc:a2b0:25d7 with SMTP id kh7csp2889595rdb; Tue, 6 Feb 2024 00:13:05 -0800 (PST) X-Google-Smtp-Source: AGHT+IGTTGYdE7VNud/w1cu9tnhbZxEWmWFjFscFouaI7hRYASqQ4sNxTgUOTAduxko3okNC03ch X-Received: by 2002:a05:6870:7195:b0:219:2a72:1c6b with SMTP id d21-20020a056870719500b002192a721c6bmr2308583oah.7.1707207185284; Tue, 06 Feb 2024 00:13:05 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1707207185; cv=pass; d=google.com; s=arc-20160816; b=DNPnqxqTXGDHbCSIr27t75ya6k2hT8l6bsPZ9hPommDWDoXANnISmrW862uqTElGts WixC8DIdHTZoNxYl2his6teq33Zq63nN5MYMZr5yqQk1h8dHGwXkVZ243913NA9WaIui gl1CzgLzSGZqdyE/yz28gqRWnCCIq0xDtbSueZ+xOFajCV9gw584risbh2y0Yld5i+Mx Ft3j1SrJp0f2jPsJXG7UnL3RLHJOyEgfmq7ujhvK54RpfO7ODu1ufHJzaqwxbkigeqPY XGfBCLj+mRJ2GU+r9lr6JqSgW0DGFoisD5SWJ5tdYGX5hLSKMS3F5vszcDoS5fQBx4sh p12Q== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:list-unsubscribe:list-subscribe :list-id:precedence:dkim-signature; bh=DVvYb92cNBYFmS/XgbWfdl+lgRph3mivnsRsqDlgiO4=; fh=GBgdikxZ9L8qRaWrnsZg9gxX805c8Mk1TJbLXWggd+Q=; b=JAPO4SZMDVQP0SmRlmTQdHVm03KJCLdy0RaUuo1elWkDsG3eWZkO/YBlwIuQX2r6UB 7PYoc8/WTn3DQ0uFKFskIyHkwBaQ8kf6elkQMCerFqVgN82PDco72GmxtWMCOmHss1a+ YC8N/QV6ckx3UxBpmaLn0gMBEnFopea0XN8EMrdoliobnAOEXbmbO26sHOT13iGvKGDb SNwa3h77563QJ4pevlNYaMHW+IvGir3eN9wqeDZib7oDpFs/5YRANP4Bg2R5QN70W1v5 FAWJcnWsL43PdT1X/8QNUiPVRoMSbqKNHr/+d4ewv4vjk958Ndr/eLEvO+9VBnlfNEk9 TtOA==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=RgcR4LAG; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-54473-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) smtp.mailfrom="linux-kernel+bounces-54473-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org X-Forwarded-Encrypted: i=1; AJvYcCXLLHV+EGV1c+VSqOTLWZZAKmq2JQtrQ7RedTmB3ubtLZMKG37FZCq1mdjKaluTcMEyK+GQ5lwxehglcI+EPkj09As4zpStJf02z/kf5g== Return-Path: Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org. [147.75.48.161]) by mx.google.com with ESMTPS id ca39-20020a056a0206a700b005dc0b1b0116si1297167pgb.119.2024.02.06.00.13.04 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 06 Feb 2024 00:13:05 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-54473-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=RgcR4LAG; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-54473-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) smtp.mailfrom="linux-kernel+bounces-54473-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sy.mirrors.kernel.org (Postfix) with ESMTPS id E4356B247B4 for ; Tue, 6 Feb 2024 08:08:26 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id E5C4A12B14B; Tue, 6 Feb 2024 08:07:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="RgcR4LAG" Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C855512A17C; Tue, 6 Feb 2024 08:07:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707206870; cv=none; b=eqXfYhRP6qrBM8XvxifVocSYaJFDQXdjCSY6xnwuCppfT1ncaOhzPxSG4do/4hYn6PG8FqlwuLuaM25Wj167KtiCgTxzqPejXotNb7dmGUbeWO8nRZvgku+3JHmQ5wQeY9oYl0TjGo9xf1drQdG5AvH5A2U13KklkObEM/BdZek= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707206870; c=relaxed/simple; bh=0KdOyQP5YNXhdX6GF4oEK/J8Apn0951e5RTs3Ez0SZU=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=p+To6pPTOV6eTAbPC4owhme7vvqmkQISqGx1xRSjLO/xAbnJ9+og7XclL+AFNEL/hV15rerzE0ZGPK0tQdxor0RglXJrZyFnxE23MDYKEsg6jVMREuAa6rSivAjZuCt6cTJROuHwiVaEWv1DNCZzRGIC9h06tXUJjYcvRy1QE8g= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=RgcR4LAG; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 721E5C433C7; Tue, 6 Feb 2024 08:07:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1707206870; bh=0KdOyQP5YNXhdX6GF4oEK/J8Apn0951e5RTs3Ez0SZU=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=RgcR4LAGY9tP1cmySGDRHutvU403efWJGrfe9/P9Ioc1r98kKKZOgK9LItwJPv1+l mzSxq90Pxain9Jvax8nseuAxkQXmkl0IBnn3GsLpkf/W6Pw/2dNZirUlfRGc2BC1d6 MQGFnRaCnn9eVhE4BNRm1Ktn+J5jDlICHi2+BPU8zEvcc71cTPznjC+DTOZ1gGKrDO Vxyz2fZbVWPJAWUVeTQOr/3P5mCIiezY+cEGZn/wEwmr4jfjYO9KMoKBu1Rvajh45k tDwGUoUcO5h4wwjfcivN3OcgFUz8yYdMf4R/yxLrmdtbi04ZSMpUqKkoacLG0JdZ87 E8rjJ/1zTJK9g== Received: by mail-lj1-f173.google.com with SMTP id 38308e7fff4ca-2d0be2cc034so3301661fa.0; Tue, 06 Feb 2024 00:07:50 -0800 (PST) X-Gm-Message-State: AOJu0YxD2E9sagbYZ8bXBW1MYyJdMEzvH5tzLVClvcd/vEx12VQhlu1F HS3d1JIr/6y3pErf2OvPK9TrajpyMuXLGKfzkbrTW3+Lfs0bYFlEWiMZ+eSzJu/xheH+9EmQvxw OqrQZVNnjPbe13Xu6+OGN5eY1pJU= X-Received: by 2002:a2e:3c16:0:b0:2d0:aca4:b955 with SMTP id j22-20020a2e3c16000000b002d0aca4b955mr1320750lja.48.1707206868601; Tue, 06 Feb 2024 00:07:48 -0800 (PST) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <2ef7d741-3df8-402a-967f-53ec77c73e2c@oracle.com> <20240125203130.28187-1-dan@danm.net> In-Reply-To: <20240125203130.28187-1-dan@danm.net> From: Song Liu Date: Tue, 6 Feb 2024 00:07:36 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [REGRESSION] 6.7.1: md: raid5 hang and unresponsive system; successfully bisected To: Dan Moulding Cc: junxiao.bi@oracle.com, gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org, linux-raid@vger.kernel.org, regressions@lists.linux.dev, stable@vger.kernel.org, yukuai1@huaweicloud.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jan 25, 2024 at 12:31=E2=80=AFPM Dan Moulding wrote: > > Hi Junxiao, > > I first noticed this problem the next day after I had upgraded some > machines to the 6.7.1 kernel. One of the machines is a backup server. > Just a few hours after the upgrade to 6.7.1, it started running its > overnight backup jobs. Those backup jobs hung part way through. When I > tried to check on the backups in the morning, I found the server > mostly unresponsive. I could SSH in but most shell commands would just > hang. I was able to run top and see that the md0_raid5 kernel thread > was using 100% CPU. I tried to reboot the server, but it wasn't able > to successfully shutdown and eventually I had to hard reset it. > > The next day, the same sequence of events occurred on that server > again when it tried to run its backup jobs. Then the following day, I > experienced another hang on a different machine, with a similar RAID-5 > configuration. That time I was scp'ing a large file to a virtual > machine whose image was stored on the RAID-5 array. Part way through > the transfer scp reported that the transfer had stalled. I checked top > on that machine and found once again that the md0_raid5 kernel thread > was using 100% CPU. > > Yesterday I created a fresh Fedora 39 VM for the purposes of > reproducing this problem in a different environment (the other two > machines are both Gentoo servers running v6.7 kernels straight from > the stable trees with a custom kernel configuration). I am able to > reproduce the problem on Fedora 39 running both the v6.6.13 stable > tree kernel code and the Fedora 39 6.6.13 distribution kernel. > > On this Fedora 39 VM, I created a 1GiB LVM volume to use as the RAID-5 > journal from space on the "boot" disk. Then I attached 3 additional > 100 GiB virtual disks and created the RAID-5 from those 3 disks and > the write-journal device. I then created a new LVM volume group from > the md0 array and created one LVM logical volume named "data", using > all but 64GiB of the available VG space. I then created an ext4 file > system on the "data" volume, mounted it, and used "dd" to copy 1MiB > blocks from /dev/urandom to a file on the "data" file system, and just > let it run. Eventually "dd" hangs and top shows that md0_raid5 is > using 100% CPU. > > Here is an example command I just ran, which has hung after writing > 4.1 GiB of random data to the array: > > test@localhost:~$ dd if=3D/dev/urandom bs=3D1M of=3D/data/random.dat stat= us=3Dprogress > 4410310656 bytes (4.4 GB, 4.1 GiB) copied, 324 s, 13.6 MB/s Update on this.. I haven't been testing the following config md-6.9 branch [1]. The array works fine afaict. Dan, could you please run the test on this branch (83cbdaf61b1ab9cdaa0321eeea734bc70ca069c8)? Thanks, Song [1] https://git.kernel.org/pub/scm/linux/kernel/git/song/md.git/log/?h=3Dmd= -6.9 [root@eth50-1 ~]# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sr0 11:0 1 1024M 0 rom vda 253:0 0 32G 0 disk =E2=94=9C=E2=94=80vda1 253:1 0 2G 0 part = /boot =E2=94=94=E2=94=80vda2 253:2 0 30G 0 part = / nvme2n1 259:0 0 50G 0 disk =E2=94=94=E2=94=80md0 9:0 0 100G 0 raid5 =E2=94=9C=E2=94=80vg--md--data-md--data-real 250:2 0 50G 0 lvm =E2=94=82 =E2=94=9C=E2=94=80vg--md--data-md--data 250:1 0 50G = 0 lvm /mnt/2 =E2=94=82 =E2=94=94=E2=94=80vg--md--data-snap 250:4 0 50G = 0 lvm =E2=94=94=E2=94=80vg--md--data-snap-cow 250:3 0 49G 0 lvm =E2=94=94=E2=94=80vg--md--data-snap 250:4 0 50G 0 lvm nvme0n1 259:1 0 50G 0 disk =E2=94=94=E2=94=80md0 9:0 0 100G 0 raid5 =E2=94=9C=E2=94=80vg--md--data-md--data-real 250:2 0 50G 0 lvm =E2=94=82 =E2=94=9C=E2=94=80vg--md--data-md--data 250:1 0 50G = 0 lvm /mnt/2 =E2=94=82 =E2=94=94=E2=94=80vg--md--data-snap 250:4 0 50G = 0 lvm =E2=94=94=E2=94=80vg--md--data-snap-cow 250:3 0 49G 0 lvm =E2=94=94=E2=94=80vg--md--data-snap 250:4 0 50G 0 lvm nvme1n1 259:2 0 50G 0 disk =E2=94=94=E2=94=80md0 9:0 0 100G 0 raid5 =E2=94=9C=E2=94=80vg--md--data-md--data-real 250:2 0 50G 0 lvm =E2=94=82 =E2=94=9C=E2=94=80vg--md--data-md--data 250:1 0 50G = 0 lvm /mnt/2 =E2=94=82 =E2=94=94=E2=94=80vg--md--data-snap 250:4 0 50G = 0 lvm =E2=94=94=E2=94=80vg--md--data-snap-cow 250:3 0 49G 0 lvm =E2=94=94=E2=94=80vg--md--data-snap 250:4 0 50G 0 lvm nvme4n1 259:3 0 2G 0 disk nvme3n1 259:4 0 50G 0 disk =E2=94=94=E2=94=80vg--data-lv--journal 250:0 0 512M 0 lvm =E2=94=94=E2=94=80md0 9:0 0 100G 0 raid5 =E2=94=9C=E2=94=80vg--md--data-md--data-real 250:2 0 50G 0 lvm =E2=94=82 =E2=94=9C=E2=94=80vg--md--data-md--data 250:1 0 50G = 0 lvm /mnt/2 =E2=94=82 =E2=94=94=E2=94=80vg--md--data-snap 250:4 0 50G = 0 lvm =E2=94=94=E2=94=80vg--md--data-snap-cow 250:3 0 49G 0 lvm =E2=94=94=E2=94=80vg--md--data-snap 250:4 0 50G 0 lvm nvme5n1 259:5 0 2G 0 disk nvme6n1 259:6 0 4G 0 disk [root@eth50-1 ~]# cat /proc/mdstat Personalities : [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] md0 : active raid5 nvme2n1[4] dm-0[3](J) nvme1n1[1] nvme0n1[0] 104790016 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UU= U] unused devices: [root@eth50-1 ~]# mount | grep /mnt/2 /dev/mapper/vg--md--data-md--data on /mnt/2 type ext4 (rw,relatime,stripe= =3D256)