All of lore.kernel.org
 help / color / mirror / Atom feed
From: Roman Mamedov <rm@romanrm.net>
To: David Hajes <d.hajes29a@pm.me>
Cc: "linux-raid@vger.kernel.org" <linux-raid@vger.kernel.org>
Subject: Re: RAID 5, 10 modern post 2020 drives, slow speeds
Date: Fri, 7 Mar 2025 23:47:53 +0500	[thread overview]
Message-ID: <20250307234753.473dc4b5@nvm> (raw)
In-Reply-To: <lMRgP8wc-P3iUlmbrsOKyuXM834ndQZZUThbeEUIO0WoNKKMQLd-T5P6QrFMEYiYAoQUAWkFGaggDTMSzZFw9KzBagunLy1mRNDk2TljKUM=@pm.me>

Hello,

On Fri, 07 Mar 2025 18:36:13 +0000
David Hajes <d.hajes29a@pm.me> wrote:

> I have issues with RAID5 running on post-2020 14TB drives.
> 
> I am getting max writting speeds of 220MBs.

What about read speeds, do you get much more, or clamped in the same ballpark?

To not wait for a full resync just to check this (or various other settings),
you can create the array with --assume-clean.

In case reads are also limited to the same value, I'd suspect PCIe bandwidth
issues, such as the HBA getting choked by 2.5 GT/s x1 for whatever reason.
Check the bandwidth in "lspci -vvv".

> I have played with chunk size...default 512k-2MBs...no difference
> 
> "Read-ahead" set for md0 virtual disk
> 
> NCQ disabled - set 1 for all physical drives
> 
> I have basically tried every suggestion on famous ArchWiki.

Do you use the Write-Intent bitmap, and what is its chunk size?
Try without one briefly, to see if this was the issue.
For production use, increase the bitmap chunk size and see if that helps.

> Initial resync drops to 130MBs

Are your drives SMR or CMR? For SMR drives it is common to briefly write
quickly and then slow down as they need to do their housekeeping during the
same time as new writes. SMR are not recommended for RAID.

> Is it possible this weird issue is linked to HDD timeout described there >>> https://archive.kernel.org/oldwiki/raid.wiki.kernel.org/index.php/Timeout_Mismatch.html

No.

-- 
With respect,
Roman

  reply	other threads:[~2025-03-07 18:53 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-07 18:36 RAID 5, 10 modern post 2020 drives, slow speeds David Hajes
2025-03-07 18:47 ` Roman Mamedov [this message]
2025-03-07 19:25   ` David Hajes
2025-03-07 20:42     ` Roger Heflin
2025-03-07 20:47       ` Roman Mamedov
2025-03-08 17:59         ` David Hajes
2025-03-12 21:09           ` David Hajes
     [not found]             ` <CALtW_ajQimm6duqkmyWbBL3MKZ9yC5Prxj=eE9vW9+pTQ=+7Eg@mail.gmail.com>
     [not found]               ` <mUTk9RKcp55IgkOLdK7prUD52e30aOJ1sQNoTaedBafMvGRVR1TxZnnBFQADU3BVc1AUfps0lsv_e9wG8PxnpXqpWt-UYKHwksp6M1b7sDU=@pm.me>
2025-03-13  6:39                 ` Fw: " David Hajes
2025-03-30  6:25 ` Xiao Ni

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250307234753.473dc4b5@nvm \
    --to=rm@romanrm.net \
    --cc=d.hajes29a@pm.me \
    --cc=linux-raid@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.