It should be worth noting that if you buy 2 exactly the same SSD's at the same time and use them in a mirror they are very likely to be wearing about the same. I am hesitant to go much bigger on disks, especially since the $$/GB really does not change much as the disks get bigger. And be careful of adding on a cheap sata controller as a lot of them work badly. Most of my disks have died from bad blocks causing a section of the disk to have some errors, or bad blocks on sections causing the array to pause for 7 seconds. Make sure to get a disk with SCTERC settable (timeout when bad blocks happen, otherwise the default timeout is a 60-120seconds, but with it you can set it to no more than 7 seconds). In the cases where the entire disk did not just stop and is just getting bad blocks in places, typically you have time as only a single section is getting bad blocks, so in this case having sections does help. Also note that mdadm with 4 sections like I have will only run a single rebuild at a time as mdadm understands that the underlying disks are shared, this makes replacing a disk with 1 section or 4 sections basically work pretty much the same. It does the same thing on the weekly scans, it sets all 4 to scan, and it scans 1 and defers the other scan as disks are shared. It seems to be a disk completely dying is a lot less often than badblock issues. On Sat, Aug 29, 2020 at 3:50 PM Ram Ramesh <rramesh2400@xxxxxxxxx> wrote: > > On 8/29/20 12:02 AM, Roman Mamedov wrote: > > On Fri, 28 Aug 2020 22:08:22 -0500 > > "R. Ramesh" <rramesh@xxxxxxxxxxx> wrote: > > > >> I do not know how SSD caching is implemented. I assumed it will be > >> somewhat similar to memory cache (L2 vs L3 vs L4 etc). I am hoping that > >> with SSD caching, reads/writes to disk will be larger in size and > >> sequential within a file (similar to cache line fill in memory cache > >> which results in memory bursts that are efficient). I thought that is > >> what SSD caching will do to disk reads/writes. I assumed, once reads > >> (ahead) and writes (assuming writeback cache) buffers data sufficiently > >> in the SSD, all reads/writes will be to SSD with periodic well organized > >> large transfers to disk. If I am wrong here then I do not see any point > >> in SSD as a cache. My aim is not to optimize by cache hits, but optimize > >> by preventing disks from thrashing back and forth seeking after every > >> block read. I suppose Linux (memory) buffer cache alleviates some of > >> that. I was hoping SSD will provide next level. If not, I am off in my > >> understanding of SSD as a disk cache. > > Just try it, as I said before with LVM it is easy to remove if it doesn't work > > out. You can always go to the manual copying method or whatnot, but first why > > not check if the automatic caching solution might be "good enough" for your > > needs. > > > > Yes it usually tries to avoid caching long sequential reads or writes, but > > there's also quite a bit of other load on the FS, i.e. metadata. I found that > > browsing directories and especially mounting the filesystem had a great > > benefit from caching. > > > > You are correct that it will try to increase performance via writeback > > caching, however with LVM that needs to be enabled explicitly: > > https://www.systutorials.com/docs/linux/man/7-lvmcache/#lbAK > > And of course a failure of that cache SSD will mean losing some data, even if > > the main array is RAID. Perhaps should consider a RAID of SSDs for cache in > > that case then. > > > Yes, I have 2x500GB ssds for cache. May be, I should do raid1 on them > and use as cache volume. > I thought SSDs are more reliable and even when they begin to die, they > become readonly before quitting. Of course, this is all theory, and I > do not think standards exists on how they behave when reaching EoL. > > Ramesh >
