jbuszkie Posted March 26, 2020 Share Posted March 26, 2020 I just added a second parity disk. That went fine. Now I'm trying to empty a disk (using unbalance) so I can finally change the few riserfs's I have left. Before dual parity, the move was about 30-45MB/s... Now with dual parity I'm hovering 13-15MB/s Is this expected? Thanks, Jim Quote Link to comment
JorgeB Posted March 26, 2020 Share Posted March 26, 2020 No, write performance should be the same, unless using a very old single core CPU. Quote Link to comment
jbuszkie Posted March 26, 2020 Author Share Posted March 26, 2020 No this is a modern 4 core.. (8 thread) i7.. Quote Link to comment
jbuszkie Posted March 26, 2020 Author Share Posted March 26, 2020 I even turned off my crash plan docker before I started it... Quote Link to comment
JorgeB Posted March 26, 2020 Share Posted March 26, 2020 3 minutes ago, jbuszkie said: No this is a modern 4 core.. (8 thread) i7.. Then dual parity isn't the reason for the slower performance, assuming the parity2 disk is working correctly, most likely it's copying small files or from a slower disk region. Quote Link to comment
jbuszkie Posted March 26, 2020 Author Share Posted March 26, 2020 1 minute ago, johnnie.black said: Then dual parity isn't the reason for the slower performance, assuming the parity2 disk is working correctly, most likely it's copying small files or from a slower disk region. No... These are DVD VOB's pretty decent size.. I just upgraded a disk. It finished before I started the move.. Everything is green.. But I wonder if it's still trying to emulate the disk I upgraded... Maybe I'll try a reboot. Also, I started a docker upgrade (just recently after I noticed the slow move) and it's taking forever! The dash board said I'm about 50-80% cpu usage... Extracting is taking forever... Once that's done I'll try a reboot, I guess... Jim Quote Link to comment
sota Posted March 26, 2020 Share Posted March 26, 2020 also what parity write strategy are you using? RMW or Turbo Write? the former would definitely be ugly. Quote Link to comment
jbuszkie Posted March 26, 2020 Author Share Posted March 26, 2020 1 minute ago, sota said: also what parity write strategy are you using? RMW or Turbo Write? the former would definitely be ugly. My md_write_method is set to reconstruct write. Quote Link to comment
jbuszkie Posted March 26, 2020 Author Share Posted March 26, 2020 I think my issue might be the fact that my destination drive is an archive (Shingled?) drive? That might be killing my writes? Jim Quote Link to comment
trurl Posted March 26, 2020 Share Posted March 26, 2020 2 hours ago, jbuszkie said: But I wonder if it's still trying to emulate the disk I upgraded... If the rebuild completed then it is definitely not emulating the disk you upgraded (unless it became disabled since, of course). Not sure why you might think that. Quote Link to comment
jbuszkie Posted March 26, 2020 Author Share Posted March 26, 2020 53 minutes ago, trurl said: Not sure why you might think that. Grasping at straws?? 😄 I think the shingled drive might be my answer... Quote Link to comment
civic95man Posted March 26, 2020 Share Posted March 26, 2020 56 minutes ago, jbuszkie said: Grasping at straws?? 😄 I think the shingled drive might be my answer... Is it slow during the entire transfer or starts fast and gradually/suddenly slows down? Its my understanding that SMR drives leverage a CMR cache area to speed up writes but once it fills then any other writes slows to a crawl. Quote Link to comment
jbuszkie Posted March 26, 2020 Author Share Posted March 26, 2020 50 minutes ago, civic95man said: Is it slow during the entire transfer or starts fast and gradually/suddenly slows down? Its my understanding that SMR drives leverage a CMR cache area to speed up writes but once it fills then any other writes slows to a crawl. I'm copying big enough files that get past the cache pretty quick, I imagine.. one thing I noticed when I broke the unbalance into smaller chunks, was that the copy would be "finished" but the remove (rm) command took a while.... or like it was waiting for the disk to be ready again before it could start the next group.. Quote Link to comment
civic95man Posted March 26, 2020 Share Posted March 26, 2020 diagnostics? preferably while in the middle of a slow transfer Quote Link to comment
jbuszkie Posted March 26, 2020 Author Share Posted March 26, 2020 (edited) I don't see anything in the syslog.. Granted I have a pre-clear running now.. But I was getting these numbers yesterday without the pre-clear.. Edit: Pre-clear Pre-read @178MB/s right now... tower-diagnostics-20200326-1619.zip Edited March 26, 2020 by jbuszkie Quote Link to comment
trurl Posted March 27, 2020 Share Posted March 27, 2020 Not related but why do you have docker image on disk2 instead of cache? Moves between disks in the array such as you are doing with Unbalance may be slower than just writing since it actually has to delete from the source after copying to destination. Also, looks like Mover was running so that might be competing for the disks. How often do you have Mover scheduled? Mover is really intended for idle time. Quote Link to comment
jbuszkie Posted March 27, 2020 Author Share Posted March 27, 2020 Quote Not related but why do you have docker image on disk2 instead of cache? I'm not sure.. It's what I did a while ago.. Maybe because I want it protected? Maybe because my Cache is only 250GB? Quote How often do you have Mover scheduled? It looks like every 4 hours.. Most of the time it doesn't run long. Crash plan runs at idle time (overnight).. And it seems to take a while to scan everything.. Quote Link to comment
trurl Posted March 27, 2020 Share Posted March 27, 2020 You want your docker image on cache so your dockers won't have their performance impacted by the slower parity writes and so they won't keep array disks spinning. There is no reason to protect docker image because it is easily recreated, and it isn't very large so there is no good reason to not have it on cache and plenty of reason to have it on cache. Does Mover really need to run that often? It really is best if you have it run at idle time, so it isn't competing for the disks. And, there is no way to move from cache to the slower array as fast as you can write to cache, so if you are writing so much to cache that you think you need to run it that often, maybe you should reconsider how you use cache. There is no requirement to cache writes to user shares. Most of my writes are scheduled backups and queued downloads. I don't care if they are a little slower since I'm not waiting on them anyway. So, those are not cached. Instead, they go directly to the array where they are already protected. I mostly use cache for my appdata and docker image so my dockers perform better and don't spin the disks, as noted. I also use cache for my plex DVR since there is some benefit to the SSD speed when trying to record and playback at the same time. My normal user share writes are not cached. Quote Link to comment
jbuszkie Posted March 27, 2020 Author Share Posted March 27, 2020 Quote You want your docker image on cache so your dockers won't have their performance impacted by the slower parity writes and so they won't keep array disks spinning. There is no reason to protect docker image because it is easily recreated, and it isn't very large so there is no good reason to not have it on cache and plenty of reason to have it on cache. I guess when I first started using dockers I might not have understood completely how they worked. I also may not have had an SSD cache drive back then? It make sense to move it to the SSD.. Quote There is no requirement to cache writes to user shares. Most of my writes are scheduled backups and queued downloads. I don't care if they are a little slower since I'm not waiting on them anyway. So, those are not cached. Instead, they go directly to the array where they are already protected. I'll have to go back and see.. My guess is some of my shares can go directly to the array.. My DVR stuff and code/work stuff will stay on the cache/array method though... I can probably change the mover to once a day... The SSD reliability is good enough that I don't have to be paranoid anymore. I do plan on upgrading to two 500GB NVME cards so I can have them in duplicate mode.... Quote Link to comment
YEAHHWAY Posted August 28, 2021 Share Posted August 28, 2021 (edited) @jbuszki did you ever figure out why your unBalance was slow? Edited August 28, 2021 by YEAHHWAY Quote Link to comment
jbuszkie Posted August 30, 2021 Author Share Posted August 30, 2021 No.. I never did... Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.