Christopher (Drashna)

We have a number of people using Windows 11 already,  but we won't say that it's officially supported until Windows 11 is no longer a beta. This is because the OS is in too much flux until it's RTM'ed, and takes a lot of work to officially support it before then. 

Christopher (at support) came back on my ticket.  He reenabled my ID and all now good.  Can write to the DrivePool.
Just in case someone else encounters this problem use a fresh trial ID to get things going while waiting for support to reenable the paid ID. 

I mean, alex is alive and well.  but yeah, some issues that don't directly involve Covecube.  
If alex wants to answer what exacty so going on, he will.  But stuff is still happening. 

First, thank you for your interest in our product(s)! 
 
 
The default file placement strategy is to place files on the drive(s) with the most available free space (measured absolutely, rather than based on percentage). This happens regardless of the balancing status.   In fact, it's the balancers themselves that can (will) change the placement strategy of new files. 
 
For what you want, that isn't ideal.... and before I get to the solution: 
 
 
 
The first issue here is that there is a misconception about how the balancing engine works (or more specifically, with how frequently or aggressive it is).
 
For the most part, the balancing engine DOES NOT move files around.   For a new, empty pool, balancing will rarely, if ever move files around.  Partly because, it will proactively control where files are placed in the first place. 
 
That said, each balancer does have exceptions here.  But just so you understand how and why each balancer works and when it would actually move files, let me enumerate each one and give a brief description of them. 
 
StableBit Scanner (the balancer). 
This balancer only works if you have StableBit Scanner installed on the same system.  By default, it is only configured to move contents off of a disk if "damaged sectors" (aka "Unreadable sectors") are detected during the surface scan.  This is done in an attempt to prevent data loss from file corruption.  
Optionally, you can do this for SMART warnings as well. And to avoid usage if the drive has "overheated". If you're using SnapRAID, then it may be worth turning this balancer off, as it isn't really needed Volume Equalization.
This only affects drives that are using multiple volumes/partitions on the same physical disk.  It will equalize the usage, and help prevent duplicates from residing on the same physical disk. Chances are that this balancer will never do anything on your system.  Drive Usage Limiter
This balancer controls what type of data (duplicated or unduplicated) can reside on a disk.  For the most part, most people won't need this.  
We recommend using it for drive removal or "special configurations" (eg, my gaming system uses it to store only duplicated data, aka games, on the SSD, and store all unduplicated data on the hard drive)Unless configured manually, this balancer will not move data around.  Prevent Drive Overfill
This balancer specifically will move files around, and will do so only if the drive is 90+% full by default. This can be configured, based on your needs. However, this will only move files out of the drive until the drive is 85% filled. This is one of the balancers that is likely to move data.  But this will only happen on very full pool.
This can be disabled, but may lead to situations where the drives are too full. Duplication Space Optimizer.
This balancer's sole job is to rebalance the data in such a way that removes the "Unusable for duplication" space on the pool.   If you're not using duplication at all, you can absolutely disable this balancer  
 
 
So, for the most part, there is no real reason to disable balancing.  Yes, I understand that it can cause issues for SnapRAID. But depending on the system, it is very unlikely to.  And the benefits you gain by disabling it may be outweighed by the what the balancers do.  
 
Especially because of the balancer plugins. 
 
 
Specifically, you may want to look at the "Ordered File Placement" balancer plugin.  This specifically fills up one drive at a time.  Once the pool fills up the disk to the preset threshold, it will move onto the next disk. 
 
This may help keep the contents of a specific folders together.  Meaning that it may help keep the SRT file in the same folder as the AVI file. Or at least, better about it than the default placement strategy.  This won't guarantee the folder placement, but significantly increases the odds.
 
That said, you can use file placement rules to help with this.  Either to micromanage placement, or ... you can set up a SSD dedicated for metadata like this, so that all of the SRT and other files end up on the SSD.  That way, the access is fast and the power consumption is minimal. 

Well, it may be worth testing on the latest beta versions, as there are some changes that may effect this, due to driver changes. 
If you're already on the beta or the beta doesn't help, please open a ticket at https://stablebit.com/Contact so we can see if we can help fix this issue. 

Yeah, it's ... manufacturer fun.   SMART really isn't a standard, it's more of a guideline, that a lot of manufacturers take a LOT of liberty with.  NVMe health is a *lot* better, in this regards (it an actual standard). 

Yes, you can do that, too.  
 
However, I generally prefer and recommend mounting to a folder, for ease of access.
 
It's much easier to run "chkdsk c:\drives\pool1\disk5", than "chkdsk \\?\Volume{GUID}"... and easier to identify.
 
 
 
Yes. The actually pool is handled by a kernel mode driver, meaning that the activity is passed on directly to the disks, basically. 
 
Meaning, you don't see it listed in task manager, like a normal program. 

StableBit DrivePool doesn't care about drive letters.  It uses the Volume ID (which Windows mounts to a drive letter or folder path). 
 
So you can remove the drive letters, if you want, or mount to a folder path. 
 
http://wiki.covecube.com/StableBit_DrivePool_Q6811286

Just a heads up, yes, it does continue to attempt to upload, but we use an exponential backoff when the software gets throttling requests like this. 
However, a daily limit or schedular is something that has been requested and is on our "to do"/feature request list.  I just don't have an ETA for when it would be considered or implemented.

LOL.  I just recently did this on my own pool, actually. 
 
 
There isn't a good way. You need to format the drives to do this (or use a 3rd party tool, and hope it doesn't corrupt your disk).
 
The simplest way is to use the balancing system.  Use the "Disk Space Limiter" balancer to clear out one or more disks at a time. Once it's done that (it make take a few hours or longer), remove the disk from the pool and reformat it. Re-add it and repeat until you've cycled out ALL of the disks.
 
 
Specifically, the reason that I mention the Disk Space Limiter balancer is that it runs in the background and doesn't set the pool to be read only. And is mostly automated.

Well, Alex has covered the development side of this, I've been looking into the pricing of the different providers.     While "unlimited" is clearly the best option for many here, I want focus on the "big" providers (Amazon S3, Azure Storage, and Google Cloud Storage).  Unfortunately, for many users, the high cost associated with these providers may immediately put them out of range. But we still think it is a good idea to compare the pricing (at least for reference sake).    All three of these providers include a storage pricing (how much data you're storing), "Request" pricing (how many API requests you make), and data transfer pricing (how much data you've transferred to and from. And all prices are listed for the US Standard region, ATM. I've tried to reorder lists, so that each provider is shown using the same layout for their different tiers.    Amazon S3     Storage Pricing (Amount stored)                                           Reduced Redundancy             Standard                  Glacier Up to     1TB / Month             $0.0240 per GB               $0.0300 per GB        $0.0100 per GB Up to   50TB / Month             $0.0236 per GB               $0.0295 per GB        $0.0100 per GB Up to 500TB / Month             $0.0232 per GB               $0.0290 per GB        $0.0100 per GB Up to     1PB / Month             $0.0228 per GB               $0.0285 per GB        $0.0100 per GB Up to     4PB / Month             $0.0224 per GB               $0.0280 per GB        $0.0100 per GB Over      5PB / Month             $0.0220 per GB               $0.0275 per GB        $0.0100 per GB   Specifically, Amazon lists "for the next" pricing, so the pricing may be cumulative. Also, "reduced Redundancy" means that they're using mostly only local servers to you, and not redundant throughout various regions.  And this is ~$25 per TB per month of storage for the Reduced Redundancy, about $30 per TB per month for Standard and $10.24 per TB per month for Glacier.   This may seem like a deal, but lets look at the data transfer pricing.   Transfer Pricing   Data Transfer In to S3 (upload)  $0.000 per GB Data Transfer OUT to the internet (download) First       1GB / Month                   $0.000 per GB Up to    10TB / Month                   $0.090 per GB "Next"   40TB / Month (50TB)       $0.085 per GB "Next" 100TB / Month (150TB)     $0.070 per GB "Next" 350TB / Month (500TB)     $0.050 per GB "Next" 524TB / Month (1024TB)   Contact Amazon S3 for special consideration   That's $92 per TB per month, up to 10TBs
Chances are, that unless you have a very good speed, that's where you're going to be "stuck" at 
 
So, that boils down to $115/month to store and access 1TB per month. Your usage may vary, but this may get very expensive, very quickly (fortunately, upload is free, so getting the storage there isn't that expensive, it's getting it back that will be).
 
Additionally, Amazon S3 charges you per transaction (API call), as well.
 
Request Pricing (API Calls)
PUT, COPY, POST, LIST Requests            $0.005 per 1000 requests
Glacier Archive and Restore Requests        $0.050 per 1000 requests
DELETE Requests                                         Free (caveat for Glacier)
GET and other requests                              $0.004 per 10,000 requests
Glacier Data Restores                                  Free
                   (due to infrequent usage expected, can restore up to 5% monthly for free)
 
Needless to say, that every time you list contents, you may be making multiple requests (we minimize this as much as possible with the caching/prefetching options, but that only limits it to a degree).  This one is hard to quantify without actual usage.
 
 
Microsoft Azure Storage   Storage Pricing (Amount stored) for Block Blob                                                                  LRS                       ZRS                        GRS                       RA-GRS First          1TB / Month                  $0.0240 per GB    $0.0300 per GB        $0.0480 per GB        $0.0610 per GB "Next"     49TB / Month (50TB)      $0.0236 per GB    $0.0295 per GB        $0.0472 per GB        $0.0599 per GB "Next"   450TB / Month (500TB)    $0.0232 per GB    $0.0290 per GB        $0.0464 per GB        $0.0589 per GB "Next"   500TB / Month (1000TB)  $0.0228 per GB    $0.0285 per GB        $0.0456 per GB        $0.0579 per GB "Next" 4000TB / Month (5000TB)  $0.0224 per GB    $0.0280 per GB        $0.0448 per GB        $0.0569 per GB Over   5000PB / Month                                      Contact Microsoft Azure for special consideration   The LRS and ZRS "zones" are priced identically to Amazon S3 here.  However, lets explain these terms: LRS:  Multiple copies of the data on different physical servers, as the same datacenter (one location). ZRS: Three copies at different data centers within a region, or in different regions. For "blob storage only". GRS: Same as LRS, but with multiple (asynchronous) copies at other another datacenter. RA-GRS: Same was GRS, but with read access to the secondary data center   And this is ~$25 per TB per month of storage for the LRS, about $30 per TB per month for ZRS, about $50 per TB per month for GRS, and about $60 per TB per month for RA-GRS.   Microsoft Azure offers other storage types, but it gets much more expensive, very quickly (double the of what's listed for Blob storage, or higher).   Transfer Rate   Unfortunately, Microsoft isn't as forthcoming about their transfer rates. They tuck it away on another page, so it's harder to access.  However, it is    Data Transfer IN  (upload)          $0.000 per GB Data Transfer OUT to the internet (download) First       5GB / Month                   $0.000 per GB Up to    10TB / Month                   $0.087 per GB "Next"   40TB / Month (50TB)       $0.083 per GB "Next" 100TB / Month (150TB)     $0.070 per GB "Next" 350TB / Month (500TB)     $0.050 per GB "Next" 524TB / Month (1024TB)   Contact Micorosft Azure for special consideration   That's $89 per TB per month, up to 10TBs
Chances are, that unless you have a very good speed, that's where you're going to be "stuck" at 
 
This is slightly cheaper than Amazon S3, but not by a whole lot, and it heavily depends on the level of redundancy and storage type you use. 
 
Request Pricing (API Calls)
Any Request                         $0.0036 per 10000 requests
Import/Export (HDDs)           $80 per drive, may not be not suitable for CloudDrive
 
 
This is definitely much cheaper than Amazon S3's request pricing.
It's still going to run you around $100 per TB per month to store and transfer, but it's a bit better than Amazon S3. And that's not counting the request transaction pricing.
 
Google Cloud Storage     Storage Pricing (Amount stored)     DRA Storage                    Standard          Cloud Storage Nearline $0.0200 per GB               $0.0260 per GB        $0.0100 per GB   DRA (Durability Reduced Availability) means that the data is not always available. While this is the cheapest, it will definitely cause latency issues (or worse).   Cloud Storage Nearly is a step cheaper, and is at a reduced performance, and has less Availability.   However, this is a flat rate, so it's very simple to figure out what your cost will be here.   And this is ~$20.48 per TB per month of storage for the DRA Storage, $26.63 per TB per month for Standard and $10.24 per TB per month for Cloud Storage Nearline.   Now lets look at the transfer pricing. Transfer Pricing   Data Transfer In to Google (upload)  $0.000 per GB Data Transfer OUT to the internet (download) First       1GB / Month                           $0.120 per GB "Next"   10TB / Month                           $0.110 per GB Over     40TB / Month (50TB)               $0.080 per GB   That's about $122 per TB per month, up to 10TBs
 
 
So, that boils down to $140/month to store and access 1TB per month. This is definitely more expensive than either Amazon S3 or Azure Storage.
 
Additionally, Google Cloud Storage does charge you per API call, as well.
 
Request Pricing (API Calls)
LIST, PUT, COPY, POST Requests       $0.010 per 1000 requests
GET, and others Requests                     $0.001 per 1000 requests
DELETE Requests                                  Free
 
Google is definitely significantly more expensive when it comes to API calls. 
 
 
 
Backblaze B2     Storage Pricing (Amount stored)    Flat Storage Rate    $0.005 per GB     The first 10GBs is free, but that's a small account, so we won't even bother computing it (it's a $0.05 difference, specifically) But that's basically $5.12 per TB per month for storage.      Transfer Pricing   Data Transfer In to S3 (upload)  $0.000 per GB Data Transfer OUT to the internet (download) First 1GB / Month                   $0.000 per GB Past 1GB / Month                   $0.050 per GB   That's $51 per TB per month transferred. This is by far, the cheapest option here.
And chances are, that unless you have a very good speed, that's where you're going to be "stuck" at 
 
So, that boils down to $56/month to store and access 1TB per month. Your usage may vary, but this may get very expensive, very quickly (fortunately, upload is free, so getting the storage there isn't that expensive, it's getting it back that will be).
 
Additionally, Amazon S3 charges you per transaction (API call), as well.
 
Request Pricing (API Calls)
DELETE bucket/file version, HIDE, UPLOAD Requests            Free
GET, DOWNLOAD file by ID/Name                                          $0.004 per 10,000 requests
Authorize, CREATE, GET, LIST, UPDATE Requests               $0.004 per 1000 requests
                   (due to infrequent usage expected, can restore up to 5% monthly for free)
 
First 2500 are free each day, and this is different from the other providers.  However, as above, it's hard to predict the usage without actual usage.
 
 

Is there a clear winner here? No. Depending on the available, amount of data and traffic, and usage, it varies depending on how you want to use the provider.
 
Well, in regards to pricing, Backblaze is clearly the winner here. But giving other issues with Backblaze (eg, sourcing, reporting statistically insignificant findings, etc), the question is "Will they be able to maintain their B2 business?" And that is a significant one. Only time will tell. 

Just a heads up, yes, it does continue to attempt to upload, but we use an exponential backoff when the software gets throttling requests like this. 
However, a daily limit or schedular is something that has been requested and is on our "to do"/feature request list.  I just don't have an ETA for when it would be considered or implemented.

Deduplication, ntfs compression, and "slack space" can all account/contribute to this. 

The local cache uses "sparse files".  These files can take up a very large space, or none at all, and they'll still report the same size.
This is how part of how we keep track of what chunks are used where, etc.
 
And if you right click on the file/folder, and check properties, you'll notice that it will report the size and size on disk, and these should be very different values. In fact, the "size on disk" should be closer to the local cache size.
 
However, the cache size isn't a hard limit for what can be stored on the disk.  We grow past that in the case that the cache is filled up completely.  
 
And if the cache is 'overfilled', as it uploads the data, it will reduce the size down until it hits the specified cache size. 
 
 
 
As for the deadlock issue, we are looking into this issue, as it is definitely a serious one. However, it is a very complicated issue, so we don't have a quick fix (we want to fix it properly, rather than half-assing it).

Wow, nice digging! 
And sorry for not getting back here sooner! 
Also, for the permissions, this should work too:
http://wiki.covecube.com/StableBit_DrivePool_Q5510455

Yup. This is an issue we see from time to time, and it's a known issue with Windows (not our software). 
Specifically, the issue is that ... sometimes, windows will not mount a volume if it doesn't have a letter (or path) assigned to it. 
Fortunately, this is a dead simple fix:
https://wiki.covecube.com/StableBit_DrivePool_F3540

Not every Cloud Provider is going to be listed. And that's okay.

For the public beta, we focused on the most prolific and popular cloud storage providers.

If you don't see a specific provider in StableBit CloudDrive, let us know and we'll look into it.
If you can provide a link to the SDK/API, it would be helpful, but it's not necessary.
 
Just because you see it listed here does not me we will add the provider. Whether we add them or not depends on a number of factors, including time to develop them, stability, reliability, and functionality, among other factors.

Providers already requested:
Mega https://stablebit.com/Admin/IssueAnalysis/15659 SharePoint https://stablebit.com/Admin/IssueAnalysis/16678 WebDAV IceDrive OwnCloud (SabreDAV) https://stablebit.com/Admin/IssueAnalysis/16679 OpenStack Swift https://stablebit.com/Admin/IssueAnalysis/17692 OpenDrive https://stablebit.com/Admin/IssueAnalysis/17732 Yandex.Disk https://stablebit.com/Admin/IssueAnalysis/20833 EMC Atmos https://stablebit.com/Admin/IssueAnalysis/25926 Strato HiDrive https://stablebit.com/Admin/IssueAnalysis/25959 Citrix ShareFile https://stablebit.com/Admin/IssueAnalysis/27082 Email support (IMAP, maybe Pop) https://stablebit.com/Admin/IssueAnalysis/27124 May not be reliable , as this heavily depends on the amount of space that the provider allows. And some providers may prune messages that are too old, go over the quota, etc. JottaCloud https://stablebit.com/Admin/IssueAnalysis/27327 May not be usable, as there is no publicly documented API. FileRun https://stablebit.com/Admin/IssueAnalysis/27383 FileRun is a Self Hosted, PHP based cloud storage solution.  Free version limited to 3 users, enterprise/business licensing for more users/features available.    JSON based API.  SpiderOak https://stablebit.com/Admin/IssueAnalysis/27532 JSON based API Privacy minded pCloud https://stablebit.com/Admin/IssueAnalysis/27939 JSON based API OVH Cloud https://stablebit.com/Admin/IssueAnalysis/28204 StorJ https://stablebit.com/Admin/IssueAnalysis/28364 Providers like tardigrade.io appear to use this library/API iDrive Amazon S3 Compatible API. No need for separate provider. ASUS WebStorage https://stablebit.com/Admin/IssueAnalysis/28407 Documentation ... is difficult to read, making it hard to tell if support is possible.  Apple iCloud https://stablebit.com/Admin/IssueAnalysis/28548 Providers that will not be added:
Degoo No publicly accessible API. Without an API that support reading and writing files to the provider, there is no possibility of adding support for this provider.  Sync.com No publicly accessible API Without an API that support reading and writing files to the provider, there is no possibility of adding support for this provider.  Amazon Glacier https://stablebit.com/Admin/IssueAnalysis/16676 There is a 4+ hour wait time to access uploaded data. This means Amazon Glacier completely unusable to us. We couldn't even perform upload verification on content due to this limitation.  HubiC https://stablebit.com/Admin/IssueAnalysis/16677 It's OpenStack - No need for a separate provider. CrashPlan? https://stablebit.com/Admin/IssueAnalysis/15664 The API provided appears to be mostly for monitoring and maintenance. No upload/download calls, so not suitable for StableBit CloudDrive, unfortunately.  MediaFire Not suitable due to stability issues. Thunderdrive No publicly accessible API. LiveDrive No Publicly accessible API. Zoolz No Publicly accessible (developer) API

You might be able to use the file placemeent rules to do this.  Eg. "/*/*/*"  However, I'm not sure that this will work.

Yes.  But YMMV. 
Mostly, having the cache on a different drive means that you're separating out the I/O load, which can definitely improve performance.   Though, this depends on the SSDs you're using.  Things like AHCI vs NVMe, and the IOPS rating of the drive make more of a difference. 

This is a topic that comes up from time to time.  
Yes, it is possible to display the SMART data from the underlying  drives in Storage Spaces.  
However, displaying those drives in a meaningful way in the UI, and maintaining the surface and file system scans at the same time is NOT simple.  At best, it will require a drastic change, if not outright rewrite of the UI.  And that's not a small undertaking. 
So, can we? Yes.  But do we have the resources to do so? not as much (we are a very small company)

This is a topic that comes up from time to time.  
Yes, it is possible to display the SMART data from the underlying  drives in Storage Spaces.  
However, displaying those drives in a meaningful way in the UI, and maintaining the surface and file system scans at the same time is NOT simple.  At best, it will require a drastic change, if not outright rewrite of the UI.  And that's not a small undertaking. 
So, can we? Yes.  But do we have the resources to do so? not as much (we are a very small company)

(also: https://wiki.covecube.com/StableBit_DrivePool_Q5510455 )

It means the pool drive.  And yeah... how Windows handles disk/partition/volume stuff is confusing... at best. 
For this ... take ownership of the folder, change it's permissions, and delete it (on the pool). 
Then resolve the issue.  It should fix the issue, and shouldn't come back. 

Awesome, glad to hear that! 
And yeah, AV can be annoying sometimes, but that it's been that long since you have had an issue is a good thing (or a horrible, horrible thing  )

This is a false positive, and happens from time to time.   And the specific "match" is the predictive engine, which is more prone to false positives. 
You can safely ignore this.