Jaga

Are you sure their surface check data didn't just age past the "Check readable / unchecked every X days" number in the preferences area? It'll do it automatically depending on the Work Window settings under the General tab. i.e. if set to "Perform work at any time of the day" and set to 90 days, any scan data aging to 90+ days will trigger a new surface scan on that drive. Also - turning on "Scan using Background I/O priority" and "Do not interfere with disk access" (higher sensitivity means less drive competition/thrashing) can help with the buffering in other apps.

Didn't think a NVMe drive running on a controller in AHCI mode would block/dishonor SMART calls - you'd think legacy compatibility would kick in at the very least. Time to do some more reading.

Click the double-right arrow to the right of the balancing bar while it's working. That will increase priority on the re-balance and speed up transfers.

I'm totally throwing out a couple of SWAGs here, but my first guess is that somehow Drivepool's command queue may be getting swamped. What DP has to do when you rename a folder: Check all drives in the pool for the existence of the folder, if you have file/folder or pool duplication going on Rename each existence if it found one The way to check and see if Drivepool is the culprit is to run it against the actual volume, not the pool itself. i.e. if your pool letter is D: and it has E: and F: in it, run the utility against both E: and F:. That takes Drivepool out of the equation, though you'll want to do a re-measure on the pool after (in case any of those you renamed were duplicated) so it can adjust. I believe DP keeps duplication info in the pool itself. If the utility ended up renaming folders that explicitly had duplication set in DP, then you'd have to go and add them again. The other possibility is that some process(es) still have handles open to those folders or files under them. If you rebooted into Safe Mode and ran the utility against the drives (E: and F: respectively), you might be able to get around those processes that lock you out of the change. It would be worth testing.

Except for the priority classes that Drivepool puts drives into. i.e. an external USB will always be in a different priority class from an internal SATA drive, no matter what (per the DP docs). I'm not entirely sure if that gives a benefit when you have super fast external drives (mine are almost as fast as my internal spinners due to their new USB connections), but it's part of the algorithm that Alex put into DP. Which is interesting. Makes you wonder if the UI is lying to you about block striping in it's UI, or if block striping needs something else to fully kick in on large files. Might have to wait for @Christopher (Drashna) or @Alex to chime in and let us know.

I was all set to agree with you Umfriend (actually had it typed in already), until I re-read the docs about read striping. Large sequential I/O uses block-based read striping, so it should have kicked in for danielb. @danielb - have you benchmarked each drive to see if there's much of a difference? It's possible that one actually is performing better than the other for some reason, and Drivepool picks up on that. What it sounds like Drivepool is doing in this case, is assigning different priority classes to the two different drives, which puts it in a situation where it would never read stripe across the two.

Awesome, glad to hear it.

Was the fix for your BIOS to update it? I think that can throw off the activation on a license. Four things you can try: Make sure you aren't running the desktop scaling higher than 100%. It can hide UI elements that you'd otherwise see in child windows. Stop/restart the Stablebit Drivepool Service on the PC (with the program closed). Restart the computer. Christopher has said in the past that can help Drivepool licensing issues. If none of those work, Contact Stablebit and let them know your problem, give them your trial activation key, and see if they can fix it for you: https://stablebit.com/Contact

If the drive works properly and Magician can get SMART, it may just be something for Alex to look at. You could try enabling Unsafe Direct IO in Scanner (once enabled you can turn it on/off per drive), but there shouldn't be any need.

If you click the small gear in the upper-right of Drivepool's GUI, choose Troubleshooting, then Service log. Have a look in there and see if you can spot the access denied errors. I'm not sure what the string would look like, but it may have the drive's device name in it. And are the files open/locked by another program currently? You can browse through the processes in Task Manager and see if there are any that may be holding them open and which shouldn't be running, then try gracefully exiting them. Or, if you can manage a reboot, that usually closes open file handles neatly, and may let Drivepool do a duplication re-check the next time you ask it to.

Then that's not the problem either. Going to guess older chipset on the lappy may be causing the issue. If you run Samsung Magician and click on the blue "S.M.A.R.T." button, can it get you the information successfully? What @Spider99 suggested with the Samsung driver might also help.

Is the controller the drive is running on in ATA mode, or AHCI?

I don't work with virtual machines much, but I do a lot of performance metrics. If there are special considerations with how the host accesses the VM files I'm not privy to them, so take my suggestions with a grain of salt. If the VM disk in this test was not inside the hidden Poolpart-xxxxx folder on that drive, then Drivepool shouldn't have been interacting with the host's access to it. Knowing exactly where it was and how you accessed it to spin up the VM for the test would help. To get an idea of what could be causing it, these are the tests I'd run and compare: Place the VM's file in the root of the volume (a volume in the pool, but not inside it's hidden Poolpart-xxxxx folder), run a test against it there. Move the VM's file into the volume's hidden Poolpart-xxxxx folder, but run the test against the local drive's letter/path (not the Pool's). i.e. if your Pool has letter D:, and the individual drive/volume has letter G, use "G:\Poolpart-xxxxx\filename.xxx" Stop the Drivepool service, then spin up the VM using the pathing from test #2 again. Start the Drivepool service. With the VM's file still inside the Poolpart-xxxxx folder, re-measure the pool. When done, run the test against the VM's file via the Pool letter/path. In tests 1 & 2 the file for the VM isn't referenced via Drivepool at all, so you're looking at Host OS access only. In test 3 we go a step further and completely disable Drivepool - if the result is different from test 1 or 2, make a note of it. In test 4 we do a regular pool access test. If the slowdowns happen even in test #3, then there may be an issue with the physical drive/controller. Theoretically all four tests should be nearly identical, from a performance perspective. That is - unless VMs have special considerations for file access. I did read a post/blog(?) from several years ago where Christopher stated the developer Alex stores his VM files in the pool, so there's a good chance it should work fine.

Oh well, that would do it. Glad you got it sorted out.

Those look right. Still, might want to re-download and do a full uninstall/reinstall. This article can help you do a full settings reset, in case nothing changes after a software reinstall.

That's a little odd, and since I can't see the primary pool setup I'm going to take a wild guess and say your plugin version and Drivepool version aren't both the latest (?) or are mis-matched. I have no idea why the plugin wouldn't display - even a 1-volume pool STILL shows me the full UI: I'd double-check versions on all Drivepool software (the main package and all the separately installed plugins), and uninstall/reinstall any that seem to be out of date. Then stop/start the Drivepool service and check again. Or for good measure uninstall all Drivepool software, re-download what you use, and reinstall it all. It won't affect the pool. Either way - I've tried toggling every setting in the main balancing Settings tab that I can think of that might affect a plugin's ability to run, and the UI for that plugin still shows for me every time. Something's wonky on your end, I think. The drives don't have to be empty for that balancer to work either - it has a setting "Control new file placement and move the existing files into the pre-defined order", which should be a retroactive setting that works on existing files (in the pool) as well as new. BUT - if you can't get the Drobo empty, then you'd have to do a rather ugly shuffle of reducing the volume size to just large enough to hold data, create a new volume in the empty space, move over what you can, and repeat ad-nauseum until you had it all on the new volume(s).

Yeah, sounds like it was just too busy trying to re-consolidate everything that was going on, and needed time to sort it out. Glad to hear you're back to normal now.

Yes it is, in fact the two work very well together. Any volume you make using Clouddrive can be used in any pool in Drivepool.

Have you tried using Windows Disk Management snap-in and creating 2 logical 5TB volumes on the Drobo? Drivepool works equally well with logical partitions, it doesn't need full physical drives. You won't get the benefit of auto-evacuation like you would with standalone drives, but you're limited by the Drobo's hardware. A combination of the Ordered File Placement plugin and hierarchical pools, you should be able to achieve what you want. Create a child pool using the 11 primary drives you want to fill up first. Then another child pool separately using the (2?) logical 5TB volumes from the Drobo. Then create a top-level pool and add in both child pools as members. Install & enable the Ordered File Placement plugin (a separate download) on the top-level pool and tell it to fill up the 11-drive child pool first, before starting to fill the Drobo child pool. The images below use some small placeholder drives to achieve, but it gives you an idea of how easy the architecture is to set up: There may be another option: talking directly to the drives in the Drobo enclosure and bypassing the controller (called Direct IO in Scanner), but I'm only familiar with how to do it in Scanner, and unsure if Drivepool offers the feature.

Normally you'd want to uninstall it manually to de-activate the license across the web. If you can't, you can always send a contact request in to support asking them to do that (giving them the email address you registered the software with, and the activation key). The contact link is https://stablebit.com/Contact More information on Clouddrive licensing can be found here: https://stablebit.com/Support/CloudDrive/Licensing

Is the colored bar across the bottom of Drivepool indicating it's trying to balance/duplicate? Have you tried clicking the small "x" to the right to cancel the operation? If you enabled pool duplication, and it ran for a while, then you disabled it.. Drivepool still has to re-measure and then do cleanup to revert it back. Since it's out of sync due to the enable/disable, it's probably unable to gather duplication stats, which is why those folder trees aren't working currently. What I'd do is make sure pool duplication is disabled, then go stop the Drivepool service, and re-start it again. Head back into Drivepool and see if it's busy trying to do cleanup. If not, click the gear in the upper-right, choose Troubleshooting, then "Recheck duplication..". When it's done with that and any work is has to do with cleanup, you may want to do a manual re-measure, and re-verify pool duplication is off.

It's a good point. I bought one of each of these for my older tower case to expand past six internal drives. Kingwin SSHD Hard Drive Enclosure Internal Five Hot Swap Bay ICY DOCK 6 x 2.5" SATA/SAS HDD/SSD Hot Swap Mobile Rack/Cage If you aren't going to invest in a half-height rack+controller+backplane for an external array (or a larger/more expensive tower), it's probably the next best option, price-wise. And with that many bays you'll have room to expand should you ever add an inexpensive internal controller.

Yep, I'm going to say that's quite possibly it as well, since all the drives are working fine for everything else. Less work for us to do, and a footnote in the support notes.

FYI - the missing drive automagically showed up after today's reboot. Didn't do any other changes or touch Drivepool settings. Funny thing is - the volume I'm caching FTP download parts onto disappeared at the same time. And it's still working perfectly mounted into a root folder on C: Is there a maximum number of volumes that Drivepool can see simultaneously? It's the only thing I can think of at the moment.

Yep - I usually stage files to be delivered to the pool on a separate volume, or in a temp folder. But glad to hear you're in the green!