Christopher (Drashna)

Well, StableBit Scanner may help. (right click on the column header and select "by controller").
 
Otherwise, you can use the Device Manager, select "View" and "Devices by connection".  You'll have to "find" the drives, but that should give you a good idea.
 
 
Though, I think this was resolved in a ticket, but not 100% sure.

Click on Help (top, right corner) and select "Safe Mode Settings". 
 
Make sure that the "DrivePool" "add-ins" are enabled, and then relaunch the dashboard. 

The ideal way is to detach the drive. But if you have a lot of data to upload, that isn't going to work, really. 
 
We don't have an outright "pause" button to do this.  It's something that's been requested, and that we will probably add.
 
In the meanwhile, open up the UI, and go to the ACD drive. Click on "Drive Options" -> Performance -> I/O Performance. 
 
This will open up a window.  Set the upload threads to "0", and this will stop it from uploading.  You'll need to set this back once you're back up and running.  
 
 
Also, data corruption won't occur regardless.  Data is not purged from the cache until we have verified that it's been uploaded. 

Alex has released a new build that should address (or at least help minimize) this issue. 
 
Specifically, it looks like this is an app wide limit on the number of API calls that needs to be "appealed" to Google to get increased, or a rewrite is needed to minimize the API calls. 
 
 
Please download 1.0.0.725 1.0.0.749 if you're experiencing this issue. 
http://dl.covecube.com/CloudDriveWindows/beta/download/

I'm sorry to hear that.  And hopefully a reload helps. 
 
 
As for the Pool and software, if the system is still "stable enough", you can deactivate the license in the software. 
 
To do so: 
StableBit DrivePool 1.X: Open the Dashboard (either remotely or locally), and click on the "Settings" button in the dashboard (top, right section). Open the "DrivePool" section in the Settings window, and click on the "manage license" link at the bottom of the page. StableBit DrivePool 2.X/Stablebit CloudDrive: Open the UI on the system that the software is installed on, click on the "Gear" icon in the top, right corner and select the "manage license" option. StableBit Scanner: Open the UI on the system that Scanner is installed on. Click on "Settings" and select "Scanner Settings". Open the "Licensing" tab, and click on the "Manage license" link. This will open a window that shows you the Activation ID, as well as a big button to "Deactivate" the license. Once you've done this, you can activate the license on a new system.     If you're not able to do this, let us know at https://stablebit.com/Contactand we can deactivate the license server side.      As for reinstallation, you can connect the drives either before or after installing StableBit DrivePool.  It doesn't really matter, actually.  As soon as the software sees the pooled disks, it will automatically ("automagically", as stated by more than a few people ) rebuild the pool with the available disks. It will remeasure the pool, and reduplicate files as needed.    This happens at pretty much any point, so there is no specific "required" order (in fact, we have a number of people that use enclosures to periodically disconnect and reconnect "removable" pools for backup, and that's handled the same way) 

Could you upgrade to the latest version? 
http://dl.covecube.com/DrivePoolWindows/beta/download/StableBit.DrivePool_2.2.0.711_x64_BETA.exe
This actually looks to be NFS server related, and ... there is a fix related to that in the newer version already. 
 
 
And if it continues to happen, grab that crash dump as well (also, you can zip it up, and it should reduce it's size SIGNIFICANTLY). 

Yes, StableBit DrivePool supports this. 
 
Specifically, there are two times when we deal with files: 
In the kernel (via the driver itself) which has no practical limitation In the service, which uses UNC pathing, which has no practical limiation  
Just keep in mind that this "fix" may cause unexpected behavior, especially in 32-bit programs. IIRC.

The issue with measuring should be fixed now.
 
However, the space reported is a problem.  This is because of how Deduplication works.  We had partial size reported, but .... 
 
There isn't a good way to handle deduplication here. Period.  Most of the data is stored outside of the pool folder strucuture, in the "System Volume Information" folder specifically.   So it's not actually pooled. 
 
Additionally, beacuse of how NTFS reports the data .... it's far from ideal. 
 
 
 
 
So, this is a known issue, but there really isn't a good way to properly handle this.  It's partially a cosmetic issue, but it's partially a technical issue. And one we aren't really sure how to handle. 
 
For now, just keep in mind that deduplication will do this, but it should work fine otherwise. 

By "G Drive", do you mean Google Drive? 
 
Also, Alex has a great writeup on how the cache works: http://community.covecube.com/index.php?/topic/1610-how-the-stablebit-clouddrive-cache-works/

Ah, yeah, "invalid file links" definitely indicate a problem with the file system. And that *could* cause it to dismount. 
 
And I'd recommend doing this sooner rather than later. 
 
if you're using Windows 8/10, you can use "chkdsk x: /scan" (where "x:" is the drive in question) to scan the disk online. It will fix what it can, but that may not be everything. 
 
 
As for the beta versions, yes. I'd recommend the 1.0.0.722 build.

I didn't see the post on the HSS forums, which is odd.... must be one of the sections i'm not manually subscribed to.
 
 
 
As long as it's a Windows 8+ machine, it *should* be able to read the drive, but I'm not too familiar with that, as I haven't tested out that scenario in a long while. 
 
But yeah....
 
 
 
Unfortunately, yeah, it's not a simple thing to do so.  Using the Server Manager to do this is the ONLY way I'd recommend, as you get more options, but even then....
 
As for the low space, that's because of the 1TB drive, and how it splits up the blocks of data.  
 
Thoough, it may also be from VSS storage, which can be pruned. Run "control sysdm.cpl", Open the "System Protection" tab, and delete the snapshots from the Storage Spaces pool. 
 
 
 
 
If you're getting a new drive here, then my recommendation would be to install StableBit Drivepool, add both the new disk and the Storage Spaces pool to a StableBit DrivePool pool.  
 
Then use the "seeding" guide to move the data in the Storage Spaces "disk" into our pool. 
 
Then ... well, remove the Storage Spaces "disk" from our pool, and this should move the contents off of the Storage Spaces "Disk" and onto the 4TB drive. 
 
Since that sounds like it should be plenty of space, once it's completed, there should be no "real data" on the Storage Spaces disk. From there, you can break it up completely, and then add the disks to the StableBit DrivePool pool. 
 
 
Details on how to "seed" the pool:
http://wiki.covecube.com/StableBit_DrivePool_Q4142489
 
Also, you will want to change the drive letter of the pool to whatever Storage Spaces was using, and then reboot. Doing this *may* "fix" everything so that the dashboard is happy and all of the shares are visible on the network. 
 
And changing the pool's drive letter is how you normally would change any disk's drive letter:
http://wiki.covecube.com/StableBit_DrivePool_Q6811286
(caveat, ignore the reported size here, it's an artifact of the driver we use)

Yes, I still recommend upgrading to this version. 
 
And no, you won't lose your data. We explicitly maintain backwards compatibility every time we implement something new or change how it works.  
 
The only time that isn't true is with Amazon Cloud Drive, because it's become a serious nightmare and we need to sit down, hammer out a new provider for it, and ... spam Amazon until they actually respond to our inquiries in a meaningful manner.

For the VMs, then I think that should be fine.
 
 
 
 
This may be because of the NICs being used.  A lot of modern network hardware has a number of defaults enabled that cause some pretty poor performance. 
 
Features that include "checksum" and "offload" in the name can do this (they offload the processing to the CPU, via the drivers so... yeah).  Also, improperly configured jumbo frames can cause performance hits. 
 
However, if the poor performance is locally, then that's a different issue.
 
As for DrivePool, I'm glad to hear it.  And yeah, it's designed to be simple. And very easily recoverable.
 
 
 
 
Thanks.  And I started with a small system. It's grown, and grown.  
 
Though, I can definitely understand the direction.  I have solar, so electricity is "free" and the savings have already paid for the installation costs. 
 
But yeah, it doesn't take a lot to run Active Directory.  
 
 
As for using 20 bays .... I'm at 23 bays used right now.   As for deleting ... I joke about "dee leet?" with friends. I like to keep pretty much everything, in case i need it.  It's a trait that I "most likely" picked up from my dad (whom was definitely a hoarder). I only hoard data (and working computers/servers), but still.  Though, it's proven to be very useful in a number of cases.
 
But yeah, anything older than Server 2008 is not supported and probably not needed. Besides, Microsoft will still keep them hosted forever, I suspect. 
 
And a very nice setup. Though, if you're keeping the drive stored at home, I'd recommend keeping them in something fire proof/resistant. 
 
 
Yes, I believe so. 
 
If you're using two pools, with no duplication, and you wanted to use SSD Optimizer for both pools, then you need to use two SSDs. Or a SSD partitioned into two volumes. 
 
But if you're using a pool with x2 duplication, then you definitely need two, physical SSDs. 

Well, glad to hear that you're loving the software!
 
Nope. Sorry. 
 
The short of it is: we don't allow that due to data sync/corruption issues with doing so.

Straight from Alex:
 

It looks like the pool didn't finish measuring properly. (the "measuring inconsistent/incomplete icon, in the bottom left section of the pie chart). 
 
Try remeasuring the pool (Pool Options -> Remeasure). 
 
If that doesn't help, then try installing the Public Beta build (if you're not using it already), as it has some code to better handle measuring issues and to better track them when errors happen. 
StableBit.DrivePool_2.2.0.651_x64_BETA
 
And after installing the beta, try remeasuring. 

Actually, could you open a ticket for this, at https://stablebit.com/Contact ?
 
Specifically, if you could grab the logs from the system?
http://wiki.covecube.com/StableBit_DrivePool_2.x_Log_Collection
 
As well as a memory dump of the service?
http://wiki.covecube.com/StableBit_DrivePool_Service_Memory_Dump
 
 
After doing this, try resetting the settings:
http://wiki.covecube.com/StableBit_DrivePool_Q2299585B

Do you mean stablebit.com/CloudDrive/Download? 

If so, no, nothing has changed and it should still be viewable.
 
 
If you mean with the dl.covecube.com site, then yeah, we did have an issue with the provider, where they temporarily lost the entire site.  This issue has been since resolved and should be working fine now. 
 
(worst case, both Alex and I have a full copy of the download library, and good redundancy for the rest of the websites)

I don't think anyone likes drives dying!  
But yeah, it's nice when our software can help make that easier!
 
And yes, you should be fine to do this.  I would recommend using eSATA (or SAS, if you have the money), as USB has issues with long term connectivity that could affect your data. 
 
And as long as the external enclosure passes the disks through to the OS, so that our software can see them, there is absolutely no issues with moving them around. 

lol.  No worries!  We've all been there!  
 
And the dashboard isn't always very intuitive, either. 
 
If you run into any other issues or have any more questions, don't hesitate to ask.

Naturally. That's the way it goes sometimes.
 
And if you're seeing it switch like that, then yes, definitely enable the NoWmi option, as that is likely why you're seeing this. 
 
Just don't forget that you'll need to restart the service, or reboot the system to get it to apply the setting.

The drives should appear regardless if they're in a pool or not.
 
The only requirement is that they be mounted to a folder or drive letter. If they're not mounted to either, then no, it won't show up. 
 
I've confirmed on several systems. 

 
If it's not displaying the drives, open up Disk management, and make sure that the drive you're trying to use has a letter or folder mount. 
 
If it does, would you mind opening a ticket at https://stablebit.com/Contact

Did you flash the bios, change the system name, or reinstall/clone the drive?  If so, these could trigger the issue. 

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. 

Okay, and as long as it's just the 2 disks, then you should be fine with doing this.
 
Once you have more than two disks, this gets a lot more complicated.