* SSDs and mdraid
@ 2021-08-24 11:14 Finlayson, James M CIV (USA)
2021-08-24 19:38 ` Phillip Susi
0 siblings, 1 reply; 3+ messages in thread
From: Finlayson, James M CIV (USA) @ 2021-08-24 11:14 UTC (permalink / raw
To: linux-raid@vger.kernel.org; +Cc: Finlayson, James M CIV (USA)
All,
As I'm trying to achieve maximum performance on mdraid with SSDs, I've noticed a situation that I think could be corrected somewhat easily.
I've been having to play the partitioning game to get enough kernel workers to achieve maximum performance on mdraid SSD stripes, but I've run into a few troubling problems. Basically on raid creation and on raid check, many events get DELAYED because they share underlying devices with other mdraid stripes when you look at the status in /proc/mdstat. I feel like mdraid hasn't made the leap to SSDs, in that we have a signal in /sys/block/<md_device>/queue/rotational that could enable these DELAYED activities for SSDs. The SSDs have way more IOPS, both read and write, to handle these DELAYs and we need to start taking advantage of the abilities of the SSDs. It is an SSD world now.
Regards,
Jim
Jim Finlayson
U.S. Department of Defense
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: SSDs and mdraid
2021-08-24 11:14 SSDs and mdraid Finlayson, James M CIV (USA)
@ 2021-08-24 19:38 ` Phillip Susi
2021-08-25 9:47 ` [Non-DoD Source] " Finlayson, James M CIV (USA)
0 siblings, 1 reply; 3+ messages in thread
From: Phillip Susi @ 2021-08-24 19:38 UTC (permalink / raw
To: Finlayson, James M CIV (USA); +Cc: linux-raid@vger.kernel.org
"Finlayson, James M CIV (USA)" <james.m.finlayson4.civ@mail.mil> writes:
> All,
> As I'm trying to achieve maximum performance on mdraid with SSDs, I've
> noticed a situation that I think could be corrected somewhat easily.
>
> I've been having to play the partitioning game to get enough kernel
> workers to achieve maximum performance on mdraid SSD stripes, but I've
> run into a few troubling problems. Basically on raid creation and on
> raid check, many events get DELAYED because they share underlying
> devices with other mdraid stripes when you look at the status in
> /proc/mdstat. I feel like mdraid hasn't made the leap to SSDs, in
> that we have a signal in /sys/block/<md_device>/queue/rotational that
> could enable these DELAYED activities for SSDs. The SSDs have way
> more IOPS, both read and write, to handle these DELAYs and we need to
> start taking advantage of the abilities of the SSDs. It is an SSD
> world now.
While there is little to no pentalty for running multiple concurrent IO
streams to the SSD, there is nothing gained by doing so either. In
other words, if you are trying to resync both mirrors on different parts
of two SSDs at the same time, each one will go half as fast, and will
take the same amount of time to finish both.
^ permalink raw reply [flat|nested] 3+ messages in thread
* RE: [Non-DoD Source] Re: SSDs and mdraid
2021-08-24 19:38 ` Phillip Susi
@ 2021-08-25 9:47 ` Finlayson, James M CIV (USA)
0 siblings, 0 replies; 3+ messages in thread
From: Finlayson, James M CIV (USA) @ 2021-08-25 9:47 UTC (permalink / raw
To: 'Phillip Susi'; +Cc: linux-raid@vger.kernel.org
IF mdraid RESYNC ran as fast as the SSDs, but it doesn't :)
-----Original Message-----
From: Phillip Susi <phill@thesusis.net>
Sent: Tuesday, August 24, 2021 3:39 PM
To: Finlayson, James M CIV (USA) <james.m.finlayson4.civ@mail.mil>
Cc: linux-raid@vger.kernel.org
Subject: [Non-DoD Source] Re: SSDs and mdraid
"Finlayson, James M CIV (USA)" <james.m.finlayson4.civ@mail.mil> writes:
> All,
> As I'm trying to achieve maximum performance on mdraid with SSDs, I've
> noticed a situation that I think could be corrected somewhat easily.
>
> I've been having to play the partitioning game to get enough kernel
> workers to achieve maximum performance on mdraid SSD stripes, but I've
> run into a few troubling problems. Basically on raid creation and on
> raid check, many events get DELAYED because they share underlying
> devices with other mdraid stripes when you look at the status in
> /proc/mdstat. I feel like mdraid hasn't made the leap to SSDs, in
> that we have a signal in /sys/block/<md_device>/queue/rotational that
> could enable these DELAYED activities for SSDs. The SSDs have way
> more IOPS, both read and write, to handle these DELAYs and we need to
> start taking advantage of the abilities of the SSDs. It is an SSD
> world now.
While there is little to no pentalty for running multiple concurrent IO streams to the SSD, there is nothing gained by doing so either. In other words, if you are trying to resync both mirrors on different parts of two SSDs at the same time, each one will go half as fast, and will take the same amount of time to finish both.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2021-08-25 9:47 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2021-08-24 11:14 SSDs and mdraid Finlayson, James M CIV (USA)
2021-08-24 19:38 ` Phillip Susi
2021-08-25 9:47 ` [Non-DoD Source] " Finlayson, James M CIV (USA)
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.