New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
Is your raid array syncing?
It's a software RAID, but I'm not sure what you mean. Wouldn't it be syncing all the time?
It won't be syncing all the time, however I believe the default configuration with OVH templates is to sync once a week.
Check the status of your RAID array.
cat /proc/mdstatPersonalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md2 : active raid1 nvme0n1p2[0] nvme1n1p2[1]
374320064 blocks [2/2] [UU]
bitmap: 3/3 pages [12KB], 65536KB chunk
md3 : active raid1 nvme0n1p3[0] nvme1n1p3[1]
64175040 blocks [2/2] [UU]
You might want to turn off that bitmap, it's bad for SSDs.
mdadm -G /dev/md0 -b none
Also see if the partitions on the SSDs are properly aligned (i.e. 4k).
(and so urban legends are born...)
OK maybe you can try explaining why would it be "bad for SSDs"?
can read up at https://raid.wiki.kernel.org/index.php/Write-intent_bitmap
bitmaps in mdadm increase more writes to the device in order to build a map the array to improve raid rebuild/recovery time and that can introduce more wear for SSDs as well as lower write performance. But I wonder if that overhead is worth faster raid array rebuild/recovery times especially for large arrays ?
I know what md bitmap is and what it does, I'm curious why @rds100 thinks it's "bad for SSDs".
Is it really just the common myth of
Then kindly wake up, an SSD is not a cheap SD card or USB stick, they are able to withstand petabytes of writes, especially not the cheapest NVMe based ones as discussed in this thread.
Operational benefits of having a bitmap (and hence near-instant array rebuilds on improper shutdown) way outweigh the silly attempt to "save SSD wear" on this.
Not to mention it's not your own SSD anyway, and in case of any wear-related issues OVH will just replace it for free.
And yes there can be reasons to disable bitmap (as it does reduce performance somewhat), or increasing its chunk size (which mitigates the performance hit), but disabling it just "because bad for SSD" should not be such a reason.
@rm_ it's bad because it is a lot of single bit changes. You know what a SSD must do in order to change a single bit in a block. For each single bit change, a whole new SSD sector must be written.
Well, on each new log file entry it's only like a 50-100 bytes change -- also causes a whole sector rewrite. What then, disable logging everywhere (web server access logs, etc)? Same for journalling in filesystems. Anything you modify creates small updates in the FS log and data allocation structures. In databases, adding or updating an entry is a small change also. Oh, let's just turn off the SSD to save the wear and move back to HDDs.
@rm_ of course you are free to use your SSDs as you like. But i would always turn off the bitmaps if i want to create a mdadm RAID of SSDs. Would make me feel better.
I suggest that you enable it, then watch after the SMART attributes 233 and 241 (record values at the start, and after a week of usage). These are "Lifetime writes to flash", and "Lifetime writes from host" on most controllers (even if labeled differently in SMART tools). If the former is higher, you do have that write amplification that you worry about (larger areas of flash are (re)written due to small actual data changes). Then compare to a week of disabled bitmaps. It won't be the cleanest of experiments, but I feel you will find the difference either way is not significant at all.