March 22, 201610 yr I didn't change the shares to be no cache, since I assumed (perhaps incorrectly) that the lack of a cache drive would make that option useless. The only thing I can think of is that the bottleneck is outside of unRAID. Can you tell me a little more about the Source Server (including its Hardware / Network Hardware / Current Network Traffic? It's an HP Proliant N40L server running Windows Server with Stablebit DrivePool. Barely any network traffic to it, as it acts as my Plex server and NAS and there is nothing going on in the house right now I don't see anywhere where you have posted a successful FAST speed to this box from your source. When writing to Cache (initially) did you see ANY speeds in the 100MB/s region? Even from another client (e.g. PC or laptop). I say this to try and eliminate unRAID as a causal factor for the slow speed. I am thinking this speed could be a READ speed limitation from your source. Thinking out loud.
March 22, 201610 yr Author I didn't change the shares to be no cache, since I assumed (perhaps incorrectly) that the lack of a cache drive would make that option useless. The only thing I can think of is that the bottleneck is outside of unRAID. Can you tell me a little more about the Source Server (including its Hardware / Network Hardware / Current Network Traffic? It's an HP Proliant N40L server running Windows Server with Stablebit DrivePool. Barely any network traffic to it, as it acts as my Plex server and NAS and there is nothing going on in the house right now I don't see anywhere where you have posted a successful FAST speed to this box from your source. When writing to Cache (initially) did you see ANY speeds in the 100MB/s region? Even from another client (e.g. PC or laptop). I say this to try and eliminate unRAID as a causal factor for the slow speed. I am thinking this speed could be a READ speed limitation from your source. Thinking out loud. It's possible it's a read speed limitation. Could be the DrivePool addon I'm running on the server or something else. That seems to be the most likely culprit given all this debugging. What's ironic is that my original parity drive speeds were the same so I could've left it enabled and saved myself the parity check by disabling and then re-enabling later.
March 24, 201610 yr Even if you use Windows copy it works perfectly fine. I've copied over 12 TB to an unRAID setup before using Windows copy. I had zero issues.
March 24, 201610 yr Author Finally got the data all copied over after 3 days using rsync on the unraid box. Painful part was reenabling parity and waiting 10 hours for it complete but at least I'm done now
March 24, 201610 yr Finally got the data all copied over after 3 days using rsync on the unraid box. Painful part was reenabling parity and waiting 10 hours for it complete but at least I'm done now Almost complete. Now that you have rebuilt your parity drive you need to check it to make sure it was built correctly. Assuming you didn't mean that above.
March 24, 201610 yr Author Finally got the data all copied over after 3 days using rsync on the unraid box. Painful part was reenabling parity and waiting 10 hours for it complete but at least I'm done now Almost complete. Now that you have rebuilt your parity drive you need to check it to make sure it was built correctly. Assuming you didn't mean that above. When I re-enabled the drive, it took 9-10hours. Isn't that equivalent to a "check"?
March 24, 201610 yr Finally got the data all copied over after 3 days using rsync on the unraid box. Painful part was reenabling parity and waiting 10 hours for it complete but at least I'm done now Almost complete. Now that you have rebuilt your parity drive you need to check it to make sure it was built correctly. Assuming you didn't mean that above. When I re-enabled the drive, it took 9-10hours. Isn't that equivalent to a "check"? No it just recreated the parity. You can tell for sure by looking at the GUI. You should see on the main tab in the GUI either "Last checked on ..." if the check has been run or "Parity check not run" or close to that I don't have any servers in that state currently to give you exact wording I'm going from memory.
March 24, 201610 yr Author Finally got the data all copied over after 3 days using rsync on the unraid box. Painful part was reenabling parity and waiting 10 hours for it complete but at least I'm done now Almost complete. Now that you have rebuilt your parity drive you need to check it to make sure it was built correctly. Assuming you didn't mean that above. When I re-enabled the drive, it took 9-10hours. Isn't that equivalent to a "check"? No it just recreated the parity. You can tell for sure by looking at the GUI. You should see on the main tab in the GUI either "Last checked on ..." if the check has been run or "Parity check not run" or close to that I don't have any servers in that state currently to give you exact wording I'm going from memory. Thanks! Didn't realize that. Just kicked off check now.
March 25, 201610 yr I'm copying over a large amount of media (movies, tv shows and music) to my new Unraid server. I have a 18TB array with a 250GB cache drive. I hope you are using a tool that is helping you "Manage" this AND not just using Windows Copy. I'm doing this myself, and what tool should I use to manage this? Historically I have been using SyncToy, but that's through windows and I'd imagine that doing it through unraid directly woudl be a better idea.
April 14, 20179 yr On 3/21/2016 at 7:20 PM, johnnie.black said: No risk, disadvantage is that all disks spin up during writes, not a big deal during the initial transfer. To turn on type: mdcmd set md_write_method 1 To turn off reboot or type: mdcmd set md_write_method 0 1 OMG THANK YOU. This took me from 30MB/s to 100MB/s.
April 15, 20179 yr Another downside of using the cache when copying data to an array is that the mover is going to want to do is moving on its schedule, and if you are still in the process of copying data, unRaid will be doing two writes to the same disk and will slow things considerably. Maybe mover has smarts to avoid this, not sure as I never cache writes. People should really rethink the cacheed writes share option and only use on shares that the slowness is actually inconveniencing then. The cache feature had its place when array writes are 10-12 Mb/sec. Now they are 4x faster and even faster if you turn turbo write on.
April 15, 20179 yr 3 hours ago, bjp999 said: People should really rethink the cacheed writes share option and only use on shares that the slowness is actually inconveniencing then. The cache feature had its place when array writes are 10-12 Mb/sec. Now they are 4x faster and even faster if you turn turbo write on. Agree. In this day and age, I think using a cache drive on shares is pointless. None of my user shares utilize the cache drive at all. It's used strictly to hold docker appdata / vm images. I average ~60MB/s writes to the array itself, and if turbo write kicks in for me I get 90+MB/s
Archived
This topic is now archived and is closed to further replies.