From mboxrd@z Thu Jan 1 00:00:00 1970 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 92BD47EE for ; Sat, 23 Dec 2023 01:48:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="mhdAXKYN" Received: by smtp.kernel.org (Postfix) with ESMTPS id 16841C433CB for ; Sat, 23 Dec 2023 01:48:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1703296120; bh=VCOX+L7TOPBA4Aof1HNWqiggph1GBeCFzguQEqX/Z1I=; h=From:To:Subject:Date:In-Reply-To:References:From; b=mhdAXKYN84DgkUdMscEQuaJgKFrM+eGiNsEpmfL23IqP9d53F4TyAb9jRjLXc/6Fd rm8qH/C4kB2UYP5FQau1Wr81F2uEWndrY9ofMYiif8sp+26+GYWgg135+SPzsff8Vq 6ZVFuMUckuckSkJGSdG0k7pJTkXoH/m/CoZ3qLCdj0VWYRiV6pQUkezXSOOooDMa2I YRzRFE9S+bhocWJ3MXDwGqTle8yBEB4QmgsT6NIaDlKDukJ0GIBOsT3Tpu740Sq48f trsd8Z90mngz1uv77EJsmpWxqX21UPOqT1s9+KDeZT2xW2KE5NcgRWdNnRJFQ5J2pV 9W9m6BJr4w6sg== Received: by aws-us-west-2-korg-bugzilla-1.web.codeaurora.org (Postfix, from userid 48) id 03024C53BD0; Sat, 23 Dec 2023 01:48:40 +0000 (UTC) From: bugzilla-daemon@kernel.org To: linux-ext4@vger.kernel.org Subject: [Bug 217965] ext4(?) regression since 6.5.0 on sata hdd Date: Sat, 23 Dec 2023 01:48:39 +0000 X-Bugzilla-Reason: None X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: AssignedTo fs_ext4@kernel-bugs.osdl.org X-Bugzilla-Product: File System X-Bugzilla-Component: ext4 X-Bugzilla-Version: 2.5 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: adilger.kernelbugzilla@dilger.ca X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: fs_ext4@kernel-bugs.osdl.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugzilla.kernel.org/ Auto-Submitted: auto-generated Precedence: bulk X-Mailing-List: linux-ext4@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 https://bugzilla.kernel.org/show_bug.cgi?id=3D217965 Andreas Dilger (adilger.kernelbugzilla@dilger.ca) changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |adilger.kernelbugzilla@dilg | |er.ca --- Comment #48 from Andreas Dilger (adilger.kernelbugzilla@dilger.ca) --- Independent of the fixes to the mballoc code to improve the allocation performance, I'm wondering about the ''RAID stride'' values in use here. The "stride" value is intended to be the size of one complete set of disks (e.g. 128KiB chunk size * 8 data disks =3D 1MiB). The filesystem doesn't see the parity disks, so the number of those disks does not matter to ext4.=20 > RAID stride: 32752 > In my case, I have an EXT4 partition over an mdadm raid 1 array of two HDD. > RAID stride: 32745 It seems in all these cases that the stripe/stride is strange. I can't see any value to setting stride to (almost) 128MB, especially not on a RAID-1 system. Were these values automatically generated by mke2fs, or entered manually? If manually, why was that value chosen? If there is something unclear in the documentation it should be fixed, and the same if there is something wrong in mke2fs detection of the geometry. > By default the FS is mounted with stripe=3D1280 because it's on a rai= d6. > Remounting with stripe=3D0 works around the problem. Excellent! Carlos, how many data disks in this system? Do you have 5x 256KiB or 10x 128KiB *data* disks, plus 2 *parity* disks? --=20 You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.=