Christopher (Drashna)

Agree.  I use Link Shell Extension, as well.  It is super useful! 
 

Is there a reason the "not more often than every X hours" option doesn't work for you? 

You may need to do this: 
https://wiki.covecube.com/StableBit_DrivePool_Q2150495

If you want to use the SSD Optimizer and use the rest of the pool,  the "simplest" option may be to use hierarchical pools.  Eg, add the SSD/NVMe drives to a pool, add the hard drives to another pool,   and then add both of these pools to a pool.  Enable the SSD optimizer on the "pool of pools", and then enable the balancers you want on the sub-pools.  

There isn't a set amount of time, because tasks like balancing, duplication, etc run as a background priority.   This means that normal usage will trump these tasks.   
Additionally, it has the normal file move/copy issue, estimates can jump radically.   A bunch of small files take a lot more time than a few large files, because it's updating the file system much more frequently.  And for hard drives, this means that the read/write heads are jumping back and forth, frequently.  
But 6-12 hours per TB is a decent estimate for removal. 

No.  Hardlinking doesn't work on the pool drive, at all, and never will.  The hard links are an object/feature of the volume, not the disk, and require that all instances of the file be on the same *physical* volume. 
They work on StableBit CloudDrive, because it doesn't emulate the filesystem the way that StableBit DrivePool does.  It handles things on a block level (below the file system, basically), and never directly deals with the file system.  Because of this,  just about anything you can do on a normal disk, you can do on the StableBit CloudDrive disks.  
But if they're pooled, then the pool's limitations still apply (at least to the pool drive).

First, I'm sorry to hear about your drive, as that is never a pleasant experience. 
 
You may be able to use "dpcmd ignore-poolpart" to eject the drive from the pool.  This marks the drive as removed, but doesn't move any of the files off of it, and causes the drive to show up as "missing" in the UI.   This does require writing to the drive, to write the tag that marks it as removed. 
Once the drive is ejected, you can manually move the files over. 
The poolID for the drive is the name of the hidden "PoolPart.xxxx" folder on the disk (with or without the PoolPart part).   
 

Correct.  Duplication is inheritted unless explicity set.  Enabling pool file duplication enables it for the root, and everything else gets inherrited.   And when you change it, it checks to see which files need to be duplicated or unduplicated (the "checking duplication" part that you may have seen).  So, it shouldn't mess with the existing data. 

Perhaps you could ask Stablebit for an extension of the trial, to test clouddrive with idrive again, via the contact form?

For reference, the beta versions have some changes to help address these: 

 
.1648 * Fixed an issue where a read-only force attach would fail to mount successfully if the storage provider did not have write access and the drive was marked as mounted. .1647 * Fixed an issue where read-only mounts would fail to mount drives when write access to the storage provider was not available. .1646 * [Issue #28770] Added the ability to convert Google Drive cloud drives stored locally into a format compatible with the Local Disk provider. - Use the "CloudDrive.Convert GoogleDriveToLocalDisk" command.  

For reference, the beta versions have some changes to help address these: 

 
.1648 * Fixed an issue where a read-only force attach would fail to mount successfully if the storage provider did not have write access and the drive was marked as mounted. .1647 * Fixed an issue where read-only mounts would fail to mount drives when write access to the storage provider was not available. .1646 * [Issue #28770] Added the ability to convert Google Drive cloud drives stored locally into a format compatible with the Local Disk provider. - Use the "CloudDrive.Convert GoogleDriveToLocalDisk" command.  

beta version: 
* [Issue #28770] Added the ability to convert Google Drive cloud drives stored locally into a format compatible with the Local Disk provider. - Use the "CloudDrive.Convert GoogleDriveToLocalDisk" command.  

it sorts by votes by default, which is ... frustrating, IMO.  

Yup.  If you mark the bad blocks as unchecked, it will attempt to scan those blocks at the next available time (typically immediately).  If the rest of the disk is marked as healthy, it will only scan these blocks (as it only scans sections of the disk that are not checked or haven't been checked in the normal scan window (30 days).
 

It depends on how the API handles it, TBH.  As long as the data is accessible, that's the important part.  However, I do believe that the account has to be writable, as some data is written to the provider when the drive is mounted (at the very least, for the "attach"/lock file for the drive.    But as shane mentioned, there was a fix related to this in the beta version.
However, we've added Google drive to the converter tool, so that you can download the contents, and convert to the local disk provider.  This is also in the beta version.
Specifically, you'd need to run "CloudDrive.Convert GoogleDriveToLocalDisk" to kick this off.
 
 

Specifically, StableBit DrivePool and Windows doesn't need letters for the disks, nor even folder mount paths.  These are there to make it easier for users to access the drives.
But as somebody with 20+ drives, mounting the drives to folders makes things very easy.  And we do have a guide on how to do so: 
https://wiki.covecube.com/StableBit_DrivePool_Q4822624

Well, StableBit DrivePool does support adding a Storage Spaces array to the pool.  So until you have more disks and are able to migrate the data away, you could add both to a pool.

Especially if this is not an NVMe drive, SSDs use all sorts of different values for SMART.   What is valid and okay for one drive may be out of spec on another drive. And that's not asuming that the OEM isn't using some sort of encryption/obsfuscation for the numbers.   Which is super common.  
NVMe has an actual, published standard, and is generally better about this (though, we've seen a few instances of issues with this). 

Definitely overthinking it.   Specifically, while StableBit DrivePool will rebalance data, most of the default enabled balancers handle edge cases, so there should be very little balancing that occurs, once the pool has "settled".   
There is a brief summary of these balancers here: 
https://stablebit.com/Support/DrivePool/2.X/Manual?Section=Balancing Plug-ins#Default Plug-ins
But for ease:
StableBit Scanner This plug-in is designed to work in conjunction with the StableBit Scanner version 2.2 and newer. It performs automatic file evacuation from damaged drives and temperature control. Volume Equalization This balancer is responsible to equalizing the disk space used on multiple volumes that reside on the same physical disk. it has no user configurable settings. Disk Usage Limiter This plug-in lets you designate which disks are allowed to store unduplicated vs. duplicated files. It doesn't do anything unless you change its settings to limit file placement on a disk. Prevent Drive Overfill This plug-in tries to keep an empty buffer of free space on each drive part of the pool in order to facilitate existing file expansion. Duplication Space Optimizer This plug-in examines the current data distribution on all of your pooled disks and decides if some data needs to be rebalanced in order to provide optimal disk space availability for duplicated files (see About Balancing for more information).  
The StableBit Scanner balancer may move stuff around a lot, but only if it detects issues with a drive.  And the Duplication Space Optimizer will try to rebalance the data to minimize the amount of "Unusable for duplication" space on the pool.  Aside from that, none of these should move data around much, normally. 

That's a plus!
That said, I know it doesn't help now, but there are a couple of posts on the forum here that cover how to index/catalog your files.  It may be worth checking those out.
Also, if it's TV shows/movies/etc, there are software that can help make inventorying them easier. 

I'm sorry to hear about the drive failure!
And yeah, any drives that were only on the drive that failed would no longer show up in the pool. 

Getting the correct power state of the disk is a little tricky. There are really 2 separate mechanisms that control whether a disk has spun down or not, the OS and the disk's firmware.
 
Here are the tricky parts:
The disk's firmware can spin a drive down at any time without the OS's knowledge. But this is typically disabled on new drives. This behavior can be modified under Disk Control in the StableBit Scanner. In order to get the actual power state of the drive we can query it directly, instead of asking Windows. The problem here is that, to Windows, this appears as disk access and it will prevent the OS from ever spinning down the drive. What the StableBit Scanner does by default is it always asks the OS and it never queries the drive directly. This ensures that the OS will spin the drive down correctly. even though we're querying it for the power state. But the issue here is that just because the OS thinks that the drive is active doesn't mean that it's actually spun up. If the disk's firmware has spun down the drive, the OS has no way to know that. The StableBit Scanner deals with this by reporting in the UI that the drive is Standby or Active. Since we can't attempt to query the drive directly without your explicit permission (this will upset Windows' power management), this is the best answer we can give you.
 
The Query power mode directly from disk option, which is found in Disk Settings, is there to work around this shortcoming. When enabled, the StableBit Scanner will attempt to query the power mode directly from the disk. Keep in mind that this can fail if it can't establish Direct I/O to the disk, in which case we fall beck to relying on the OS.
 
The way it works is like this:
Query the OS. If the disk has spun down then this must be the case. The disk is in Standby. If the disk is Active (spun up) then we can't trust the OS because the disk firmware could have spun it down. If the user has not explicitly allowed us to query the power mode from the disk, we must assume Standby or Active. If the user has allowed us to query the power mode from the disk, query the power mode. If the query succeeds, set the mode to Active or to Standby (not both, because we know the power state for sure). If the query fails, fall back to the OS and set the mode to Standby or Active. So when should you enable Query power mode directly from disk?
 
When you don't want to use the OS's power management features to spin the disk down. Why would you do this?
 
Pros:
You can control the spin down on a per disk basis. You get exact disk power states being reported in the StableBit Scanner with no ambiguity. Avoid disk spin up issues when querying SMART (I will explain below). Cons:
Requires Direct I/O to the disk. To the OS (and to any other program that queries the OS) the disk will appear to be always spun up. When the OS spins down a disk it flushes the file system cache prior to spinning it down. This ensures that the disk is not spun up very quickly after that because it needs to write some additional data to it from the cache. When the firmware spins a disk down, this does not happen and there is a chance that the disk will be spun up very quickly after that to perform another write. From my experience, this is not common in practice. What about S.M.A.R.T. queries?
 
In the StableBit Scanner, by default, SMART is queried from WMI first. If Direct I/O is not available then all the SMART data has to come from WMI. Typically this would not spin up a disk.
 
If Direct I/O is possible to the disk then at least some additional SMART data will come from Direct I/O (and if WMI doesn't have the SMART data then all of the SMART data comes from Direct I/O). One potential problem here is that Windows considers any communication with the disk, disk activity. So if you're communicating with the disk to retrieve SMART every couple of minutes then Windows will not spin the disk down.
 
You can avoid this problem in 2 ways:
Don't let Windows control your disk spin down and set up a Standby timer in Disk Control (this has the pros and cons as outlined above). Set Throttle queries in Settings -> Scanner Settings -> SMART -> Throttle queries. Set the throttle minutes to something higher than the Windows disk spin down time (which can be examined in Power Options under the Windows Control Panel). The option Only query during the work window or if scanning controls SMART queries and has no effect on power queries. Again, by default power queries do not spin up a disk unless you've manually enabled Query power mode directly from disk (in which case you are effectively saying that you don't want the OS to ever spin down a disk).

You also opened a ticket for this. 
But to repeat what I said there, and echo what vapechiK said, 
This is perfectly normal, and expected.  In all cases, here. 
the pool drive itself is fully virtual, but doesn't have any blocks/data on the drive. All of the data is "reverse proxied" to the underlying disks, and handled invisible.  So CHKDSK won't work on the drive, and it does not appear in StableBit Scanner.   And the size is normal, as Windows needs a size before that can be properly read, so the 2TB size is a placeholder. 

Reparse point information is stored in the .covefs folder in the root of the pool.  Worst case, delete the link, remove the contents of the .covefs folder, and then reboot. 

Reparse point information is stored in the .covefs folder in the root of the pool.  Worst case, delete the link, remove the contents of the .covefs folder, and then reboot.