craigr Posted March 11, 2018 Share Posted March 11, 2018 Disk15 in my array is a btrfs formatted SSD drive. I am trying to run TRIM on it. I have entered the following command and gotten the output: root@Tower:~# fstrim -v /mnt/disk15 fstrim: /mnt/disk15: the discard operation is not supported It's an old Patriot Pyro 60GB drive and I think it's firmware supports TRIM... I am about to replace it with a new 240GB SSD (that I know supports TRIM) and want to make sure TRIM will work on it. Is my command correct? Could someone please tell me if the "Dynamix SSD TRIM" app works on array drives or if it only works on cache drives? If Dynamix SSD TRIM only works on cache drives, what would be the easiest way to schedule TRIM daily on an SSD array drive? PS there is a good reason I have an SSD drive in my array for my application. Thanks to anyone who can help. Best regards, craigr Link to comment
JorgeB Posted March 11, 2018 Share Posted March 11, 2018 Do you have the SSD connected on one of the LSI HBAs? If yes use the onboard SATA instead as SAS2008 don't support trim on most SSDs. Link to comment
craigr Posted March 11, 2018 Author Share Posted March 11, 2018 6 hours ago, johnnie.black said: Do you have the SSD connected on one of the LSI HBAs? If yes use the onboard SATA instead as SAS2008 don't support trim on most SSDs. The SSD is connected to the motherboard SATA controller. That drive never worked right connected to the LDI's I tried root@Tower:~# fstrim -v /mnt/disk with the new SSD using unassigned devices and it worked last night, so I don't think I have a problem there. I suspect at this point the the Patriot Pyro may not support TRIM. It is a very old drive at this point. Any idea if "Dynamix SSD TRIM" will work on drives in the array. In one spot Bergware noted that it's for cache drives, but in another it's noted, "Dynamix SSD trim creates a cronjob to do regular SSD TRIM operations on all mount points which support the operation." But I looked at the code last night and it seems to be just for the cache drives... I tried my hand at editing the code, but couldn't get the app to load once I mucked with it. craigr Link to comment
John_M Posted March 11, 2018 Share Posted March 11, 2018 The fstrim command is built into the unRAID OS. The Dynamic plugin just allows you to schedule it in a convenient way from the GUI so there's nothing to be gained by editing the code. Link to comment
BRiT Posted March 11, 2018 Share Posted March 11, 2018 Beware that running TRIM on Array Drives has the potential to corrupt Parity, depending on how the drives handle the TRIM operation. Link to comment
craigr Posted March 11, 2018 Author Share Posted March 11, 2018 1 hour ago, BRiT said: Beware that running TRIM on Array Drives has the potential to corrupt Parity, depending on how the drives handle the TRIM operation. I've heard that, but also heard that it's not true... Can anyone say conclusively? I suppose I could run TRIM and do a parity check without correcting data errors, but if there are error than I will have to run parity again to rebuild parity... craigr Link to comment
craigr Posted March 11, 2018 Author Share Posted March 11, 2018 1 hour ago, John_M said: The fstrim command is built into the unRAID OS. The Dynamic plugin just allows you to schedule it in a convenient way from the GUI so there's nothing to be gained by editing the code. Well, it looks like "Dynamix SSD TRIM" only runs on cache drives... that's what I need to know! Will it run on my array SSD?!? craigr Link to comment
BRiT Posted March 11, 2018 Share Posted March 11, 2018 2 minutes ago, craigr said: I've heard that, but also heard that it's not true... Can anyone say conclusively? I suppose I could run TRIM and do a parity check without correcting data errors, but if there are error than I will have to run parity again to rebuild parity... craigr Yes, this is conclusive. It depends on how your SSD handles TRIM. It's why LT does not suggest to use SSD in the array. The main issue with running TRIM on SSDs in the array is that it changes the data at the sector level without letting the MD device (unraid's /dev/md/) know about it. In that situation the parity is thrown off. There's additional technical information around in the forums, even some posts directly from LimeTech, but good luck on trying to find it because the search feature on these forums is even worse than the previous one. You'll have to use google or bing to search these forums for any chance of finding it. Link to comment
John_M Posted March 11, 2018 Share Posted March 11, 2018 7 minutes ago, craigr said: I've heard that, but also heard that it's not true... Can anyone say conclusively? I think this is about as conclusive as it comes. 7 minutes ago, craigr said: Will it run on my array SSD?!? No. I don't believe it will. Link to comment
craigr Posted March 11, 2018 Author Share Posted March 11, 2018 3 minutes ago, John_M said: I think this is about as conclusive as it comes. No. I don't believe it will. I'm honestly not sure how that link is conclusive. craigr Link to comment
JorgeB Posted March 11, 2018 Share Posted March 11, 2018 fstrim -v /mnt/disk15 I didn't notice you were running trim on an array disk, trim is disabled on array disks by design, since it would invalidate parity. Link to comment
craigr Posted March 11, 2018 Author Share Posted March 11, 2018 5 minutes ago, johnnie.black said: I didn't notice you were running trim on an array disk, trim is disabled on array disks by design, since it would invalidate parity. OK this may explain why I can't get TRIM to work on my current SSD within the array. I am pretty sure it supports TRIM even though it is very old. What I use the SSD drive for is to store the data form my media player movie wall. It contains thousands of small files and the SSD drive feeds them to the GUI on the media player much faster than a spinner. I really want to run an SSD drive there, but maybe I shouldn't or maybe I should just not use TRIM. Or occasionally remove the drive from the array and run trip on it and then rebuild the array... Sigh, craigr Link to comment
John_M Posted March 11, 2018 Share Posted March 11, 2018 4 hours ago, craigr said: I'm honestly not sure how that link is conclusive. It isn't, which is precisely my point. Link to comment
BRiT Posted March 11, 2018 Share Posted March 11, 2018 The statements made in this thread explain the situation and are conclusive. I don't know what more anyone is looking for, perhaps 3 large billboards? Link to comment
trurl Posted March 11, 2018 Share Posted March 11, 2018 4 hours ago, craigr said: What I use the SSD drive for is to store the data form my media player movie wall. It contains thousands of small files and the SSD drive feeds them to the GUI on the media player much faster than a spinner. Maybe something here for you. There are ways to use cache settings to keep some files on cache and some on array, but requires a bit of manual upkeep. https://lime-technology.com/forums/topic/46802-faq-for-unraid-v6/?page=2#comment-537383 A user share is just the combined top level folders on cache and array with the same name. The cache settings control where files are written for the share, but all disks are used when reading from the share. Link to comment
pwm Posted March 12, 2018 Share Posted March 12, 2018 11 hours ago, BRiT said: Yes, this is conclusive. It depends on how your SSD handles TRIM. It's why LT does not suggest to use SSD in the array. The main issue with running TRIM on SSDs in the array is that it changes the data at the sector level without letting the MD device (unraid's /dev/md/) know about it. In that situation the parity is thrown off. There's additional technical information around in the forums, even some posts directly from LimeTech, but good luck on trying to find it because the search feature on these forums is even worse than the previous one. You'll have to use google or bing to search these forums for any chance of finding it. Without TRIM, unused sectors will keep their previous contents after files have been erased. After TRIM, they will not. So I'm not sure any SSD can safely handle TRIM in a parity-protected array unless the system knows which sectors that has been trimmed and recomputes the parity for these sectors. The safe way is to use a SSD that has overprovisioning and do not need any TRIM to maintain good write speeds. This functionality is normal for enterprise-grade SSD. When used outside of parity-protected arrays, they can still make good use of TRIM to reduce wear - TRIM informs them which unused parts of flash blocks that doesn't need to be copied to new flash blocks when rotating in new flash blocks from the overprovisioning pool. Link to comment
craigr Posted March 13, 2018 Author Share Posted March 13, 2018 On 3/11/2018 at 6:41 PM, trurl said: Maybe something here for you. There are ways to use cache settings to keep some files on cache and some on array, but requires a bit of manual upkeep. https://lime-technology.com/forums/topic/46802-faq-for-unraid-v6/?page=2#comment-537383 A user share is just the combined top level folders on cache and array with the same name. The cache settings control where files are written for the share, but all disks are used when reading from the share. 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 Link to comment
craigr Posted March 13, 2018 Author Share Posted March 13, 2018 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 Link to comment
trurl Posted March 13, 2018 Share Posted March 13, 2018 What I had in mind for you was to store the metadata on cache, and the media on the array, and not get mover involved at all. Mover only moves cache-yes and cache-prefer shares. The other 2 settings will just leave the files wherever they are. Why I said there would be some manual upkeep is because it would be up to to you put the metadata on cache and put the media on the array, but they could all be in the same user share and so would look like they were in the same location to your clients. Link to comment
craigr Posted March 13, 2018 Author Share Posted March 13, 2018 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 Link to comment
bonienl Posted March 13, 2018 Share Posted March 13, 2018 7 hours ago, craigr said: 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." I am using a Dune media player too. I have attached a SSD drive to the Dune player and use Zappiti to generate metadata which is stored on the local SSD. When zapping thru my media collection, it will retrieve the information locally and only when I want to play something, it makes access to my media server. Link to comment
craigr Posted March 14, 2018 Author Share Posted March 14, 2018 18 hours ago, bonienl said: I am using a Dune media player too. I have attached a SSD drive to the Dune player and use Zappiti to generate metadata which is stored on the local SSD. When zapping thru my media collection, it will retrieve the information locally and only when I want to play something, it makes access to my media server. 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 Link to comment
craigr Posted March 14, 2018 Author Share Posted March 14, 2018 18 hours ago, bonienl said: I am using a Dune media player too. I have attached a SSD drive to the Dune player and use Zappiti to generate metadata which is stored on the local SSD. When zapping thru my media collection, it will retrieve the information locally and only when I want to play something, it makes access to my media server. 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 Link to comment
Recommended Posts
Archived
This topic is now archived and is closed to further replies.