Edrock200

Disregard, ran a chkdsk, it repaired some issues, and it stopped cycling. Sorry for raising the flag early.

The latest version of cloudiness goes through Pinning data cycles every 60m or so. They generally last 30m or so and uploads/downloads seem to come to halt while this process occurs. Anyone else seeing this?

Just to add to this, from the other thread, I started manually stopping the service vice dismounting the drive prior to a pc reboot. Last night, the service shut down cleanly after a few minutes without any intervention. Unfortunately upon restart it began the chunk id rescan/rebuild and took several hours. I've also recently received "Access Denied" when attempting to detach my drive on random occasions. I've been able to get around this by offlining the drive in windows disk manager, then detaching. Interestingly, one time when remounting after doing this, Windows (not cloud drive) mounted the drive as read only. I was able to use the diskpart utility to make it writable again.

Not sure if this is related to your issue, but I had drive corruptions as well with my 256tb cloud drive. Chkdsk would detect the errors, but could never repair them. I then found an article on Microsoft's knowledgebase stating that chkdsk repairs require the Volume Shadow Copy service, and that service does not work on partitions over 64TB. I couldn't shrink my partition size in clouddrive, but I could drink in in Windows Disk manager to 50TB, then I was successful in having chkdsk repair the volume.

Some good reference info: https://gist.github.com/0xbadfca11/da0598e47dd643d933dc and here: https://charbelnemnom.com/2016/01/how-to-recover-data-on-refs-volume-between-different-windows-server-2016-technical-preview-builds-refs-ws2016-hyperv/

In addition to av, you'll also want to turn off windows indexing on the hidden cache drive directory

This is why I would still encrypt: Q: Who manages the encryption keys?+ A: The keys are managed by Microsoft.

To the op, if you clear your cache does it "jump start" for a while? If so, assuming connectivity is good, could be a cache drive I/o issue, prefetch settings, or something is trying to do aggressive random read/writes to the drive. Open perfmon and check drive tab for details on which processes are reading and writing to what files.

Fwiw I ran into this problem too when seeding my drive with Google drive sync. What I found was Google drive writes temp files to a hidden directory on the same drive your seeding, then copies them over when complete. This causes constant requests to the same chunks, eventually causing throttling then disconnects. If your seeding method works the same way you can try my fix. I changed the cache mode from fixed to proportional and left it at 50/50 so the temp chunks could stay in read cache. Before I did this my downloads were constantly at least 50% of my upload speeds even though I don't have verify chunks on nor was I doing any reads against the drive, and eventually disconnects. Prefetch was unusable. After changing it barely reads during seeding and prefetch works. The only time I get slow downs are when my disk I/o on cache drive can't keep up, but generally only lasts a few seconds but doesn't cause disconnects. Here's my settings: 50tb clouddrive encrypted 80gb proportional cache 50/50 10 dl threads 5 ul threads Prefetch trigger 5mb Prefetch fwd 50mb (have tested UpTo 200mb w/o issue but found anything over 50 didn't increase overall avg read speed during burst transfers). Get steady ~15-20MB (150-200mbs) read speed on burst transfer downloads with these settings. Have gig connection but upload throttled to 350 and dl to 250mbs. Unlocking these throttles did not increase download speeds with prefetch set higher. Uploads would surge to 550+ then get throttled by Google regardless of thread count. Time window 30 seconds Upload chunk 20mb Download size 5mb (anything larger caused disconnect/throttling issues and slow performance, and lower would cause the same issues due to clouddrive thread count surge when it tries to catch up) Chunk cache size 100mb Provider Google drive Drive indexing disabled Antivirus scans disabled on drive Not sure if drive pool will support, but if your using encryption for each drive you may want to make your drives decrypted, add to drive pool, then use bitlocker to encrypt drive pool drive so your CPU isn't doing multiple encryption/decryption cycles against the same data. I would also disable read striping until your seeding is complete to prevent a download thread surge.

first instinct is to say congrats yet doesnt sound right at the same time happy to hear your working again

it appears to be normalized now. Fingers crossed for you! You might want to try editing the Program Files/Stablebit/Clouddrive/Clouddrive.service.default.config file to up the timeout and retry threshold/tolerance counts, then restart the service.

FYI in case anyone is getting Google drive disconnects: https://www.google.com/appsstatus

Thanks Christopher! Just to clarify, I see the Native service is listed as "Stablebit CloudDrive Shutdown Service", this is in addition to the primary Stablebit CloudDrive Service. I'm assuming I should stop down the primary "Stablebit Clouddrive Service." If so, I can just create a batch file with elevated privileges to to stop the service then restart the machine whenever I need to restart. Thanks again!

Right, I was just wondering if there is a manual way to initiate that process other than initiating a system shutdown. Are you saying stopping the shutdown service will do that?

Make sure you turn off drive indexing and exclude your drive from scheduled antivirus scans.