Shane

File Placement will override the SSD Optimizer unless "File placement rules respect real-time file placement limits set by the balancing plug-ins" is checked in the Balancing menu's Settings tab. E.g. if you have File Placement saying "all new files go on drives X, Y and Z" and SSD Optimizer saying "all new files go on drives A and B" then all new files will go on X, Y and Z unless the above setting is checked.

When you say "the system was choking", do you mean DrivePool or Windows?

Okay, I've messaged Stablebit about this, hopefully you should get a response soon (nb: I consider "soon" to be within 2-3 days, excluding weekends, based on previous history; your mileage may vary). Please let me know either way.

When you say you emailed support, do you mean literal email or did you use the Contact form? When you typed in the activation key, did you include the curly brackets { } ?

@WestSidaz I think you need to tick "File placement rules respect real-time file placement limits set by the balancing plug-ins" and (maybe) untick "Balancing plug-ins respect file placement rules"? @RobbieH Rules set in the File Placement tab may override the SSD Optimizer if "Balancing plug-ins respect file placement rules" is ticked or "File placement rules respect real-time file placement limits set by the balancing plug-ins" is unticked. Also, if Automatic Balancing is not enabled, the SSD Optimizer will never be triggered to flush the drive(s) marked as SSD. Does that help? Regarding developer support for DrivePool, I believe the forums are intended more to provide a place where the community can assist each other; in cases where that doesn't help you and you need direct developer support for an issue you should be following up by using the contact form. I've always found the latter gets a prompt response when I've run into a problem the forums couldn't fix. EDIT: @gtaus is correct that this thread is an old one that has been marked solved (back in 2016!) and that really all the later questions should have been asked in their own new threads. What's done is done, though.

That is odd. Still, if there's no files in D:\ when you look at it in explorer then you should be able to safely Remove the E:\ "disk" from the D:\ pool and thus delete the D:\ pool without affecting the E:\ pool.

I'm out of ideas. Probably need to open that support ticket, sorry. Let us know how it goes?

1. Do you encounter the problem when you copy from a local disk on the pool computer to the pool via the pool's network share (e.g. "\\poolcomputer\poolshare\") instead of via the pool's drive letter (e.g. "P:\")? 2. Is there any difference between copying over the network from another computer to the pool via a mapped network drive (e.g. "P:\") versus the UNC share (e.g. "\\poolcomputer\poolshare\")? 3. On the source/target computers, has there been a network driver update (or any other update) around or shortly before the time this started happening? (check the Windows Update history)

No typo; it makes the offer anyway. I assume it's just a default "there's a duplication problem, here's a thing I can try" response, and if you tell it to go ahead it doesn't succeed since in this case there is no older file. If the content is different, then yes. Correct, DrivePool makes no decisions based on file content. You could request that the developer add that feature (deleting the different file) as an option?

SnapRAID is popular with some users of DrivePool for this reason since the two can be used together. As gtaus mentions, MultiPar is another option. Testing 3x duplication recheck (on 2.3.0.1244 BETA): date modified is different file content is identical -> DrivePool does nothing file content or size is different -> DrivePool alerts the user and offer to delete the older version date modified is identical file size is different -> DrivePool will alert the user and offer to delete the older version file size is identical file content is identical -> DrivePool does nothing file content is different -> DrivePool does nothing. So if the damage includes a change to date or size, then it will alert you that there's a discrepancy and offer to delete the older version (which may not be what you want in this case); if the damage is only to the content (e.g. a "k" is replaced with a "q"), then it won't detect it.

Not that I'm aware of. A workaround might be to keep a record on the pool of the files that are on each backup drive? 1. backup the files 2. if all goes well, then do something like "dir backupdrive:\ /s /b > pooldrive:\backuplog\backupdriveserial.%date%%time%.log" 3. remove backup drive

Hmm. What happens if you tick Bypass File System Filters under Manage Pool -> Performance? Have you changed or updated your antivirus software, if any? (note: antivirus software may continue to interact at the driver level even when supposedly "off" according to the user interface; you may need to uninstall the antivirus software completely for it to be actually off).

DrivePool's duplication is primarily intended to help with losing a drive; if individual files are being corrupted it may or may not be able to help depending on the situation. In this case where you know the corruption is limited to files on a single drive, if you're using pool-level duplication then the safest thing to do is let DrivePool re-duplicate the pulled drive using the rest of the drives: "Remove" the missing drive and it should proceed to re-duplicate (if not, you can use Cog icon -> Troubleshooting -> Recheck Duplication). Once you've got the pool fully duplicated again, you can format the corrupted drive (or at least delete/rename the hidden poolpart) and then re-connect it (in that order, as current versions of DrivePool will automatically attempt to re-add it to the pool and in this case you don't want that). However, if you've got insufficient free space on the remaining disks to re-duplicate the pool, or you're certain that only the 0kb files are the files that have been corrupted (that the remaining files on that drive are bit-for-bit intact) then you could just delete the 0kb files, re-connect the drive and tell DrivePool to Recheck Duplication. This will certainly be quicker since the pool will have less files that need re-duplicating. Short answer is it can't know. It checks each file's attributes and if they don't match then it runs a check of the content. If that also doesn't match then it alerts the user and offers them the choice of fixing it themselves or (if applicable) letting DrivePool replace the "older" instances.

Other registry changes to try (separately or together): HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management PagedPoolSize (REG_DWORD, Hexadecimal) to ffffffff (that's eight 'f' characters) DisablePagedPoolHint (REG_DWORD, Decimal) to 1 These changes should be reverted if they don't help. You could also try resetting security permissions on the pool (yes, that sounds weird but yes, it may fix it).

You can wait for it to eventually detect the excess duplication and correct it automatically, or you can use the Troubleshooting menu (from the Cog icon) to manually Recheck Duplication immediately. Either way it should reclaim the free space. Another concern to check however is whether you made any changes to files on the pool between removing the disk and later reconnecting it? If so, you could potentially have issues (e.g. if you removed a drive, deleted a file from the pool that was on that drive, then reconnected the drive, the file would effectively be un-deleted; similarly if you moved a file that was on that drive, a copy would re-appear at the old location; etc).

Yes, that's correct.

Perhaps you could work around the problem with a third-party copier (e.g. UltraCopier, FastCopy or Copy Handler) or file manager (e.g. Double Commander), as some use their own copying code (to varying degrees) rather than rely on Windows?

You'd need a plugin to accomplish this. You could try a feature request via the contact form?

If it is not already present, try adding PoolUsageMaximum (REG_DWORD, Decimal, 60) to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Memory Management in the registry. If it is already present but higher than 60, record its value and try changing it to 60. In both cases a restart will be required.

DrivePool has the dpcmd CLI tool, but I couldn't find any options re indicating missing disks. You could test by copying a file to the pool - if it succeeds, there are no missing disks (since pools become read-only while disks are detected missing). I see another problem however - if it is critical that disks not be missing, and if there is no checking during the sync operation itself, then there is no protection against the risk of a disk going missing during the sync operation? Therefore if a disk going missing means the sync will remove files from the cloud, that indicates you are not using (full) duplication - perhaps you could sync from the individual disks that make up the pool, that way if a disk goes missing during the sync then the sync itself could stop?

You could use the Ordered File Placement balancer (or the corresponding sections of the All In One balancer) to tell DrivePool that it should use that drive last for both new and existing files, so that it would re-balance your files into the other drives?

No, as the evacuation feature overrides the Automatic balancing section (because if you're using the evacuation feature, you want it to get to work the moment it notices a problem). So you would also want to do at least one of the following: configure the StableBit Scanner entry in the Balancers tab as you prefer (for example, you could turn off everything under File Evacuation while turning on Temperature Control) un-tick the StableBit Scanner entry in the Balancers tab to disable it completely (if you don't want Scanner and DrivePool to interact at all) un-tick the "Allow balancing plug-ins to force immediate balancing" in the Settings tab if you do not want ANY balancer to be able to override the Automatic balancing section of the Settings tab.

I'd take a wild stab and say probably negligible difference so long as windows is idle and behaving; checking task manager, my fileserver's boot SSD is currently averaging ~1% active time, ~450 KB/s transfer rate, ~1ms response time and <0.01 queue length over 60 seconds at idle, and it's a rather old SATA SSD. I think you're much more likely to run into other bottlenecks first. But YMMV as it depends how many simultaneous streams are you planning for, what other background programs you have running, etc. You could test it? Open task manager / resource monitor, set to show the drive's active time, transfer rate and queue length, then open some streams while you run an antivirus scan or create a restore point and so on?

Sorry, I haven't used CloudDrive nearly enough to be able to tell you whether your plan is actually sound (I use DrivePool and Scanner a lot more) though that may change in the near-ish future. "Drive Usage set to B only having duplicate files." - Have you tested that this works with a pair of local pools? If so, it should also work with a local+cloud pool pairing. "Is read striping needed for users of Pool C to always prioritize Pool A resources first?" - According to the manual the answer is no; regardless of whether Read Striping is checked it will not stripe reads between local and cloud pools, instead it tries to only read from the cloud pool if it can't read from the local pool. However, I have noted forum posts about issues with getting DP to prioritise correctly, and I don't know if those issues have been fixed since those posts as I haven't dug through the CloudDrive changelog recently. https://stablebit.com/Support/DrivePool/2.X/Manual?Section=Performance Options. The rest of your plan seems sound.

Yes; the response handled via a balancer in DrivePool, which you can configure or disable as you desire.