Jump to content

jbuszkie

Members
  • Content Count

    608
  • Joined

  • Last visited

Community Reputation

3 Neutral

About jbuszkie

  • Rank
    Advanced Member

Converted

  • Gender
    Male
  • Location
    Westminster, MA

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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.. 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....
  2. Does this plugin normally do more than one rsync at a time? My move seems to be nearly stalled.... This is moving to a SMR drive so I expect it to be slower.. but it seems to be crawling! root@Tower:~# ps auxx | grep rsync root 7754 0.0 0.0 3904 2152 pts/0 S+ 08:33 0:00 grep rsync root 31102 8.4 0.0 13412 3120 ? S 07:55 3:08 /usr/bin/rsync -avPR -X T/DVD/MainMovie/FILE1 /mnt/disk8/ root 31103 0.0 0.0 13156 2308 ? S 07:55 0:00 /usr/bin/rsync -avPR -X T/DVD/MainMovie/FILE1 /mnt/disk8/ root 31104 9.7 0.0 13240 2076 ? D 07:55 3:38 /usr/bin/rsync -avPR -X T/DVD/MainMovie/FILE1 /mnt/disk8/ root@Tower:~# It did this yesterday too... Thanks, Jim Edit: The sysylog doesn't show any obvious errors...
  3. 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? 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..
  4. 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
  5. 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..
  6. Grasping at straws?? 😄 I think the shingled drive might be my answer...
  7. I think my issue might be the fact that my destination drive is an archive (Shingled?) drive? That might be killing my writes? Jim
  8. My md_write_method is set to reconstruct write.
  9. 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
  10. I even turned off my crash plan docker before I started it...
  11. No this is a modern 4 core.. (8 thread) i7..
  12. 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
  13. Bump.. I assume this hasn't been implemented yet? I'm rebuilding a data disk and I almost had to reboot the system (I think crash plan was bringing my system to a halt..) I was able to stop crash plan and the system started responding again.. But I'd love for it to remember where is was during a disk rebuild/parity check/Parity build... Jim
  14. That will work!! I didn't see the advanced settings! Thanks!
  15. *pout* Not what I wanted to hear.. But what I expected to hear... Thanks for confirming, Squid....