craigr

OK, you guys were totally correct. I messaged Limetech directly about this and he sent me links with detailed instructions on how to get overprovisioning to work based on these methods. It looks like he posted the details to this thread already Here are the two paramount links: You must first perform a secure erase: https://www.thomas-krenn.com/en/wiki/SSD_Secure_Erase Then use hdparm: https://www.thomas-krenn.com/en/wiki/SSD_Over-provisioning_using_hdparm I now have a 256GB 840PRO that shows 230GB in Unassigned Devices Very kind regards, craigr

Thank you so much. That was very easy and it worked perfectly. I now have a Samsung 840 PRO 256GB that shows 230GB in Unassigned Devices. Now all I have to do is swap out the old SSD and rebuild. Awesome! Do you mind if I share your instructional post on the public forum? I certainly do not know. I found it impossible to even discover what drives support DZAT. I did a lot of googling and the only reference I found was a guy on a random forum stating that his 840 PRO supports DZAT and that his 850 PRO does not. He wanted to know if Samsung had any plans to support DZAT on the 850 PRO in the future. I would like to know if Samsung supports DZAT on the 860 or 960 as well. Based on that one piece of information I rolled the dice and bought the 840 PRO on eBay for $65 with only 31 days of use and about 1TB written. I probably saved myself some money anyway versus buying a newer drive I really expected to find a compiled list of know drives that support DZAT someplace, but I uncovered nothing of the sort. I would have liked to have bought a more modern drive, but I didn't want to get stuck with a drive that did not support DZAT. I did buy an "Inland Professional 240 GB" budget drive at Microcenter for $50 and checked it. The drive did not sport "DZ_TRIM" or "DX_TRIM" so I returned it. However, One of the difficulties in searching is what to search for; DZAT, DZ_TRIM, Deterministic read zeros after TRIM... I suspect if you build unRAID to support DZAT the community will quickly compile a list. That said, surely there are other situations other than unRAID where this information must be required? Thanks again, Craig Rounds

Yeah, I follow what you are saying. Kind regards, craigr

...but that defeats the purpose than doesn't it Thanks again, craigr

Hmmm... but will an HPA partition be usable for over provisioning by the drive? Could I delete the HPA partition after the array is setup and parity is finished? Or maybe if I just create the HPA partition and don’t format it? If I later delete the HPA partition, based on what you say I think it likely that unRAID will then see the disk as unmountable and want me to format it using the entire disc... Thanks for all the help! craigr

Oh. I must have obviously been missing something! I may look into this more now. It would be nice to not have to totally redo parity and a lot of other stuff... clearly. Thanks for the help guys. craigr

I'm thinking the best thing to do may be to create a new config in unRAID. I used "Unassigned Devices" to create an XFS partition on the new Samsung SSD. I then used cfdisk to resize the partition with a bit over 10% overprovisioned. I copied all the contents from my existing SSD drive in the array to the new drive in "Unassigned Devices." When I created this array I stupidly assigned my 64GB SSD to disk15 which at the time was my last disc... now I have a 64GB disc in the middle of my array. I am planning to copy the unRAID flash drive with my current config as a backup. I'll then create a new config. I have extra 8TB drives on hand so I will remove the existing parity drive and swap it with a new one. I'll pull the old SSD and install the new. I'll then assign the new 8TB drive as parity, assign my new SSD as disk 1, and assign the rest of my data discs while making sure my cache drive is the cache drive again. At that point I can rebuild parity with my overprovisioned new SSD. If anything goes wrong during parity rebuild, I can reinstall the original parity drive and SSD drive, and restore the unRAID flash backup... I think that will all work? I just hope overprovisioning doesn't disrupt parity or I will be going back to rebuilding with the new SSD without overprovisioning. craigr

Well, regardless my Supermicro board does not have it. Thanks for the help. craigr

I am pleased to report:

Neat idea, but I don't think my Supermicro board supports this. Also, I want to leave 10% of the dis unallocated and I don't think HPA will reserve that much space. I had an HPA board once and I think that it only consumed a couple megabytes. craigr

As I understand it, the Samsung 840 PRO has the necessary provisions in its firmware to use unallocated space on the disc for overprovisioning. The installer simply has to determine how much space is warranted for overprovisioning and then just leave the space unallocated. One the Samsung 840 the recommended amount is 10%. I have read that in Windows this is all that the Samsung "Magician" tool does. It suggests that you leave some "X" amount of space unallocated, and then the hard drive controller firmware already knows what to do with it for wear leveling. I may write Limetech directly about this. It seems there must be a way to instruct unRAID to not allocate the entire disk during a new disc rebuild when using a larger disc in the old disc's place. I also need to make sure this wont have a deleterious effect parity... Thanks for your input, craigr

I use one SSD drive in my array it works perfectly well with parity because it supports "Deterministic read data after TRIM" ("DX_TRIM"). However, my current 64GB SSD drive has gotten too small for my needs, so I just ordered a "new" Samsung 840 PRO. Limetech says they are likely to support TRIM on array drives in the future. However, Limetech also says that they may only support "Deterministic read zeros after TRIM." The reason I went for the 840 PRO is because it's the only drive I could find that I was sure supports "DZ_TRIM" mode and I want to be as certain as possible that my SSD will support unRAID array TRIM in the future. My question is, is it necessary (or good practice), and is it possible, to overprovision my new SSD drive? When I replace the old small drive with the new larger drive unRAID will automatically want to format it and rebuild the array. Is there any way that I can make unRAID leave 10% of the drive unformatted so that the drive can utilize overprovisioning? Here is a link to Limetech about TRIM on array drives: Thanks for any help! Kind regards, craigr

Thanks for this post. Right now I have one SSD in my array that has been there for years and has not been at all problematic. It uses "Deterministic read data after TRIM." However, this drive is getting too small for my needs and I want to get a larger drive now, so naturally I want to make sure it is compatible with unRAID TRIM in the future. If only DZ_TRIM is going to be supported, I want to find a disc that supports this. I however can't figure out a way to discover what type of TRIM any given SSD supports short of buying it and putting it into a Linux machine and checking. Is there a list or any reference available to figure out what SSD drives support DZ_TRIM TRIM? That said, there are also several hardware versions of the 840 PRO so who knows if they all handle TRIM the same way?!? I read a random post in some random Linux forum that the Samsung EVO 840 PRO supports DZ_TRIM but that the 850 does not. That is literally all the info I can find about SSD drive trim types after a lot of Googling. Anyone have any guidance? Thanks, craigr

Just wanted to let everyone know that I tested this script on 6.5.0 today and it does work perfectly. Thanks again, craigr

So I guess there was a server migration or the forum software was changed, what, about a year ago? I noticed it but didn't give it much thought as I wasn't changing anything on my unRAID server and hadn't needed any help. The past few weeks I have been doing a lot with my server and realized my sig might be helpful in some posts. So why the heck are signatures turned off by default since the forum migrated to it's new platform? Kind regards, craigr

If your talking about the link for 2.6.5 in your first post of this thread, that is the one that does not work for me. bonienl's link to his edited script does work. So I think there is either something wrong with your script link or maybe something with PeaZip that doesn't extract properly... I just started trying PeaZip so it's new to me. Either way, I got it running with bonienl's unzipped link. Again, thanks John for maintaining this script. It just helped me again and proved all my drives of the same model are running at about the same speed so I will stop worrying Kind regards, craigr

Ah yes, thank you. Grabbed the modified script from bonienl's post... working now! craigr

I extracted it from Windows using PeaZip directly to the unRAID flash drive over the network. Thanks, craigr

I'm really under the weather, so maybe I am missing something, but I can not get diskspeed_2.6.5 to do anything correctly under unRAID 6.4. I want to upgrade to 6.5, but I really want to check the speeds of all my discs first because I think one is slowing down my parity check. My hardware config is in my signature. All drives are spun up, but when i type diskspeed.sh or diskspeed.sh -s 11 -i 1 this is the output I get: What stupid thing am I doing wrong? Also John, do you think you will need to make any changes for 6.5? It seems that it may not need any updates. Thanks for the hard work. I've been using your script for several years and it is very helpful. Best regards, craigr

Yes, that does work well and the DUNE's can act as an SMB server too (I use yaDIS). Thing is we have three DUNE players and I like to fully power them down when they are not in use (not just standby power off). I have considered just leaving one of them on in standby with the SSD inside and keeping the SSD out of the array, but than I still don't get TRIM It is very fast when the SSD is local instead of on the network, but it's only one out of three players in my case. I just wish there was a way to make a disc NOT part of the array that can be included in a user share and also not interrupt the normal use of MOVER. Either a second cache drive or something like unassigned devices... only have them assigned just not part of the parity array. Good thoughts though so thank you. Best craigr

Yes, that does work well and the DUNE's can act as an SMB server too (I use yaDIS). Thing is we have three DUNE players and I like to fully power them down when they are not in use (not just standby power off). I have considered just leaving one of them on in standby with the SSD inside and keeping the SSD out of the array, but than I still don't get TRIM It is very fast when the SSD is local instead of on the network, but it's only one out of three players in my case. Good thoughts though so thank you. Best craigr

True. I guess it would work if I didn't user mover on the "Media" share and just either moved manually or wrote directly to the desired disc in the array. Thanks, craigr

This feature seems to be exactly what I need; two separate cache drives not a cache pool. It needs to have a share that's included in a user share. I hope this feature comes along soon! Thanks, craigr

Well, it looks like this won't work. I have never worked with a cache pool in unRAID before so I'm hoping to be wrong... However, it seems that once the cache pool is assigned more than one disc, it's impossible to selectively choose which disk files are added to in the cache pool? Thus, it also seems impossible to assign a user share on one disc in the cache pool to move the data to the array with mover, while on the second disc to NOT move the data in the same user share to the array? I seem to be dead in the water again :-( Best regards, craigr

Yes, this may actually be very helpful. I am looking into this option now and doing preliminary research. My issue is that my media players can only have one SMB connection at a time (I consider this a huge oversight on the part of DUNE), hence all of the data I need to access needs to be in a single user share "Media." If I look at my media wall GUI on the media player, it must be within the same share as the video file that I then select to play. Otherwise, the media wall and the actual video require two SMB connections and it will not play. If I can setup a second cache drive using an SSD, and simply never use mover on that drive, than I can include what I need in the Media share on the second cache drive to maintain a single SMB connection per media player. I have never tried a cache pool on unRAID. Right now I just have a 3TB spinner that acts as cache and the Docker drive. I could possibly remove the SSD from the array, rebuild parity with one less drive, and then make the second cache drive the SSD and keep the files there. Then I can use TRIM on the SSD cache drive and NOT mess up parity. Time to do some reading... Thank you so much! I hope this works. Another thing I considered was using unassigned devices, but from what I recall, unassigned devices shares cannot contribute to an unRAID user share? Kind regards, craigr