Christopher (Drashna)

You can do this: https://wiki.covecube.com/StableBit_DrivePool_Q4822624
This hides the letters, and keeps the drives accessible. 

This is part of the problem with the way that the SSD optimizer balancer works. 
 
Specifically, it creates "real  time placement limiters" to limit what disks new files can be placed on.  
 
 
 
I'm guessing that the SSD is below the threshold set for it (75% by default, so ~45-50GBs).  Increasing the limit on the SSD may help this (but lowering it may as well, but this would force the pool to place files on the other drives rather than on the SSD). 
 
 
Additionally, there are some configuration changes that may help make the software more aggressively move data off of the drive.
http://stablebit.com/Support/DrivePool/2.X/Manual?Section=Balancing%20Settings
On the main balancing settings page, set it to "Balance immediately", and uncheck the "No more often than ever X hours" option, it set it to a low number like 1-2 hours. 
 
For the balancing ratio slider, set this to "100%", and check the "or if at least this much data needs to be moved" and set it to a very low number (like 5GBs). 
 
This should cause the balancing engine to rather aggressively move data out of the SSD drive and onto the archive drives, reducing the likelihood that this will happen.
 
 
Also, it may not be a bad idea to use a larger sized SSD, as the free space on the drive is what gets reported when adding new files. 

This is part of the problem with the way that the SSD optimizer balancer works. 
 
Specifically, it creates "real  time placement limiters" to limit what disks new files can be placed on.  
 
 
 
I'm guessing that the SSD is below the threshold set for it (75% by default, so ~45-50GBs).  Increasing the limit on the SSD may help this (but lowering it may as well, but this would force the pool to place files on the other drives rather than on the SSD). 
 
 
Additionally, there are some configuration changes that may help make the software more aggressively move data off of the drive.
http://stablebit.com/Support/DrivePool/2.X/Manual?Section=Balancing%20Settings
On the main balancing settings page, set it to "Balance immediately", and uncheck the "No more often than ever X hours" option, it set it to a low number like 1-2 hours. 
 
For the balancing ratio slider, set this to "100%", and check the "or if at least this much data needs to be moved" and set it to a very low number (like 5GBs). 
 
This should cause the balancing engine to rather aggressively move data out of the SSD drive and onto the archive drives, reducing the likelihood that this will happen.
 
 
Also, it may not be a bad idea to use a larger sized SSD, as the free space on the drive is what gets reported when adding new files. 

Just a heads up, this is a known issue, and we are looking into a solution for this issue (both to prevent it for new drives and for existing drives).
I don't have an ETA, but we are actively working on it. 
 

Unfortunately, we don't have any plans on adding support for WSL2 at this time. 

Unfortunately, we don't have any plans on adding support for WSL2 at this time. 

You can reset the status, and it will flag it to get scanned. 
https://stablebit.com/Support/Scanner/2.X/Manual?Section=Disk Scanning Panel#File System Health
 

No issues.  I've been using SMR drives personally since Seagate released the Archive drives.  And I have a pool of mixed drives.  WD Reds, Seagate NAS, Seagate Archive. 
The only caveat is that the SMR drives have a "write cache" of non-SMR space. If you fill that (fairly easy to do so), the write speeds get atrociously slow.   Because of this, I would recommend using the SSD optimizer, to effectively bypass this issue.  Doesn't matter if balancing is slow, since it is  any ways.
In fact, that's the setup that I have (for years now), and it works wonderfully. 

welcome!  And yeah, it's a really nice way to set up the system.  It hides the drives and keeps them accessible, at the same time. 

Full Stop. 
 
No. 
 
The Read Striping may improve performance, but we still have the added overhead of reading from NTFS volumes.  And the performance profile for doing so.
 
RAID 1 works at a block level, and it's able to split IO requests between the disks.  SO one disk could read the partition table information, while the second disk starts reading the actual file data. 
 
This is a vast oversimplification of what happens, but a good illustration of what happens.
 
 
So, while we may read from both disks, in parallel, there are a number of additional steps that we have to perform to do so. 
 
 
 
To be blunt, the speed is never going to rival hardware RAID.   However, between with disk switching, and the reading blocks of the file and caching into memory. 
 
 
 
 
 
That said, you should still see at least the native disk speeds, or a bit better. But this depends on what the disks are doing, specifically. 
 
 
 
 
CrystalDiskInfo probably isn't going to get great stats because of how it tests the data.
 
At best, enable pool file duplication, so that EVERYTHING is duplicated.  Make sure Read Striping is enabled, and then test. 

I guess that would really depend on the client/server/service, and how it handles uploaded files. 
However, it shouldn't be an issue, in most cases. 

You can remove the drive letters and map to folder paths.  We actually have a guide on how to do this:
https://wiki.covecube.com/StableBit_DrivePool_Q4822624
It would be, but the only problem is that it would be too easy to break existing configurations.  Which is why we don't have the option to do so.   
 

Thanks for the response. Turns out, I was clicking on the down arrow and that did not give the option of enable auto scanning. So after reading your response, I clicked on the "button" itself and it toggled to enabled. Problem solved. Auto scanning immediately started so I know that it is working. Thanks.

It is. 
However, you should be able to set the "override" value for "CloudFsDisk_IsDriveRemovable" to "false", and it may fixe the issue. But the drive will no longer be treated as a removable drive. 
https://wiki.covecube.com/StableBit_CloudDrive_Advanced_Settings

Nope, definitely not dead! 
But if it's urgent, or basically, it's the best way, direct any support queries to https://stablebit.com/Contact

StableBit DrivePool doesn't have a master and subordinate/duplicate copy. Both are equally viable, and treated as such.  This is very different from how Drive Bender handles things.5
As for being documented, not really, but sort of. Eg: https://wiki.covecube.com/StableBit_DrivePool_Knowledge_base#How_To.27s
 
That said, if the data is in the same relative path under the PoolPart folders, they're considered duplicates.  Changing the duplication settings, or even remeasuring can kick off a duplication pass that will automatically prune the duplicates, as needed. 
Also, the "dpcmd" utility has an option to disable duplication for the entire pool, recursively. However, that kicks off a duplication pass that actually manages the files. 
Just have both products installed. That's it.  You can fine tune settings in StableBit DrivePool, in the balancing settings, as the "StableBit Scanner" balancer is one of the 5 preinstalled balancer plugins. 

That should be fixed now.  Though, the file system scan won't trigger the drive evacuation.  And yeah, that fix was shipping in the 2.5.5 version, and the latest stable release is 2.5.6, so this definitely shouldn't be an issue anymore.  (we haven't seen it in a while). 
 

Now I have an image of you having some sort of steampunk mechanical networking setup...

Honestly, I'm not sure.    I suspect that the processing is per drive, rather than duplicated/unduplicated, first.   
Since I'm not sure, I've opened a request, to ask Alex (the Developer).
https://stablebit.com/Admin/IssueAnalysis/28301
 
  
Not currently.   It would require a change to both StableBit DrivePool and StableBit Scanner to facilitate this.  
My recommendation would be to just evacuate unduplicated data on SMART warnings. 

So when you add a 6TB HDD to that setup, and assuming you have not tinkered with the balancing settings, any _new_ files would be stored on that 6TB HDD indeed. A rebalancing pass, which you can start manually, will fill it up as well. With default settings, DP will try to ensure that each disk has the same amount of free space. It would therefore write to the 6TB first until 4TB is fee. Then equally to the 6TB and 4TB until both have 3TB free etc. The 500GB HDD will see action only when the others have 500GB or less available.
This is at default settings and without duplication.

I believe you need to seed the pool. See Pool Seeding

To clarify (and make it simple to find), here is Alex's official definition of that "Other" space:
 
 

Yeah, as long as the drives show up correctly, then it will maintain the pool. 
 
As for the power savings, that entirely depends on the power consumption, both at peak and idle.  
And to be honest, you probably won't see a lot of power savings.  The best way to get that savings is to use large capacity SSDs, which is what data centers do.  However, they can be a LOT more expensive. 

I'm always impressed with the extent you go to help people with their questions, no matter how easy it complex.   Thanks Chris.  

Yes, that's definitely a false positive. 
 
It's just some of the troubleshooting stuff for the UI.  It's nothing harmful.  
 
And if you check, the file should be digitally signed.  A good indicator that it's legit. 

Sure. I purchased and installed PartedMagic onto a USB. I then booted using this USB to run a Secure Erase, but it was not able to complete successfully. So I ran DD (through PartedMagic as well) on the drive around 5 times. I then converted the disk to GPT using diskpart and installed a fresh copy of Windows. I used CHKDSK, StableBit Scanner, and Intel SSD Toolbox (Full Diagnostic) to confirm that read/writes were functioning as intended. 
Based on what I could understand from Intel, it seems like the Optane drives are fairly unique due to their usage of 3D XPoint technology which caused the specific/strange behavior I was facing. 

I definitely suggest configuring snapraid so it points to the drivepool folder with the GUID inside the config file so that it's much easier to restore. Snapraid doesn't have to be the root of the drive, it can be anywhere you like (as long as they are on different psychical drives).
So instead of doing:
data d1 z:\ data d2 y:\ data d3 x:\ You do:
data d1 z:\drivepool.{guid}\ data d2 y:\drivepool.{guid}\ data d3 x:\drivepool.{guid}\ That way after a failure e.g d2 dies, you drop your new drive in, add it to the pool, get the new GUID from the new drive, and edit your snapraid conf to comment out the old drive and add the new one by changing d2 y:\drivepool.{guid}\ to d2 y:\drivepool.{newguid}\ like so:
data d1 z:\drivepool.{guid}\ #data d2 y:\drivepool.{guid}\ data d2 y:\drivepool.{newguid}\ data d3 x:\drivepool.{guid}\ Then run your fix and it all just works - and you don't have to move your files around.