From: Mariusz Tkaczyk <mariusz.tkaczyk@linux.intel.com>
To: Juan P C <audioprof2002@hotmail.com>
Cc: "linux-raid@vger.kernel.org" <linux-raid@vger.kernel.org>
Subject: Re: missing Levels.
Date: Tue, 13 Feb 2024 11:03:40 +0100 [thread overview]
Message-ID: <20240213110340.00003b37@linux.intel.com> (raw)
In-Reply-To: <BN0PR20MB4088BAB7BB75BACB62A29567B2492@BN0PR20MB4088.namprd20.prod.outlook.com>
On Sun, 11 Feb 2024 18:58:00 +0000
Juan P C <audioprof2002@hotmail.com> wrote:
> Seems odd, there are missing Raid levels.
what is the point here? Why it is odd? Implementation is driven by needs so we
care of what is wanted on the market. We don't have to implement all invented
raid levels.
>
> dont know the history of linux-raid changes log,
> but seems someone made a bad decision in the past.
Bad decision? I don't think so. You are using strong words as a new person in
this community. Why you are trying to judge was is better? I don't feel that
you are right person to make any statements especially attacking previous
maintainers of this product.
>
> Let me explain:
>
> Enmotus FuzeDrive 1.6TB its actually a QLC 2TB M.2 NVMe PCIe
> that Requires Windows Raid drivers.
>
> Has built-in different technologies, All-in-one.
>
> #1. Smart Cache RAID mode...
> Small fast SSD + Larger HDD.
> Similar to intel Optane or Apple Fusion Drive,
> But both solid, smarter,
> defrag the ssd,
> moves most access files to Cache drive,
> and files with less access to Main/Large storage.
>
> #2. RAID2 mode.
> the drive is partitioned in 2.
> 1/4 of the 2TB QLC is used in Raid level=2 mode.
>
> The reason is to emulate an SLC with QLC.
> Increase speed & longevity by 4x
> By reducing size 1/4.
Oh, here is the trade-off.
I don't think that performance (speed?) is increased because you need to update
multiple chunks to save data which is obviously memory and time consuming.
Full stripe writes are not limited with this solution. At a first glance, it is
a performance killer.
>
> Real SLC are very expensive & power hungry.
> QLC are cheap.
So you expect features to repair you budget? Well, that is not a purpose of
RAID array. We cares to not make situation worse, not to fix media issues.
It can be done in firmware if needed. We can make some low-cost
optimization but we cannot risk huge performance impact.
>
> Basically 2 Raids in 1.
> Inception.
Did you heard about MD stacked raid or IMSM matrix raid?
>
>
> Linux-Raid, should have at least Raid level=2
> To create SLC, MLC or TLC from QLC, TLC, MLC ssd drives.
>
Go ahead and implement it then, it is open source but.. We will decide if it is
worthy. There is no data that can prove efficient of your solution, it is more
marketing speaking now.
> for example:
> Samsung 970 Pro is MLC "2-Bit" PCIe v3.0
> Samsung 980 Pro is TLC "3-Bit" PCIe v4.0
> Crucial MX500 is TLC,
> Crucial BX500 is QLC "4-Bit", No Dram.
> etc...
>
> Smart Cache Raid is interesting,
> But more complex,
> would requiere creating a second Journaled log file, or an enhanced version.
>
> Temp folders are usually better on Ram drives of 4GB.
>
> There is a ramdrive for linux, with Cache or Not, just drive.
> Called rapiddisk on github.
> By pkoutoupis
> But the lack of Raid level = 2 is devastating for Linux.
>
It is not devastating, that is not true. You came here to say "I have a great
solution for QLC drive, you have to do this". You cannot demand that. If you
want something you are free to write it and we together will decide if it is
good.
For me, this is a trade-off between performance, size and nvme lifetime. There
are reasons why RAID2 is dead, binary layout is not efficient. Dividing raid
array into 3/4 for data and 1/4 for RAID2 seems weird to me.. Why not 3/5 and
2/5? It is always trade-off between multiple factors. You care the most about
SSD lifetime, I have different opinion and I see performance as crucial.
Thanks,
Mariusz
prev parent reply other threads:[~2024-02-13 10:03 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-11 18:58 missing Levels Juan P C
2024-02-12 16:19 ` Phillip Susi
2024-02-13 10:03 ` Mariusz Tkaczyk [this message]
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=20240213110340.00003b37@linux.intel.com \
--to=mariusz.tkaczyk@linux.intel.com \
--cc=audioprof2002@hotmail.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).