Christopher (Drashna)

Make sure that the "Start / stop automatically" button is highlighted.
 
If that is, and it still hasn't scanned, and it's been more than 45 days, let me know.

If you used the "Duplicate data later" option when removing the disk, then the data left would be duplicated data. 
 
If you check the "PoolPart.xxxxx" folder, you can see what was left over, and it should be in the same relative location as the pool. 

It's hard to tell.  If it continues to occur, then it may be an issue. 
 
And in that case, you may want to reduce the number of IO threads are being used, as this help. 

First, try installing this version: 
http://dl.covecube.com/ScannerWindows/beta/download/StableBit.Scanner_2.5.2.3124_BETA.exe
 
And then you can force it to rescan the "damaged" sectors. To do so, double click on the drive in question, click on the 4th button down on the left side (it should have a green circle), and select "mark unreadable sectors as unchecked". 
 
If the issue comes back, then there may be a problem.   In this case, try accessing "\ProgramFiles\CLink4\Service_trace.0.log" and see if that has issues.  If it does, then there definitely is an issue with the drive. 
 
Another thing to test is the "Burst Test". Right click on the drive and select this option. Let it run overnight (or longer) and see if that comes back with any errors.  If this does, then there may be a communication issue with the disk. 

Double click on the drive, click on the 4th button down (green circle on it) and select "Mark drive as unchecked" 

Did StableBit CloudDrive indicate that it was running recovery on your drives? 

If so, there was an issue where the data was getting corrupted by Google (it's a long explanation).  The newest version attempts to automatically repair that data, but it may not be 100%. 
 
In this case, if your drives did get repaired, it *could* cause this. 
 
 
That said, this issue is no longer an issue.  We've made changes that will absolutely make sure that this CANNOT happen in the future. 
 
 
 
 
 
That said, StableBit DrivePool does write identical files, and ties to make sure of this.
If/when there is an issue, it will be flagged in the UI.  However, this relies on accessing the file, in most cases.  It will check the file modify date and if that doesn't match, then it will run a CRC check on the files.  
 
However, given the above issue, the dates may have been fine, so it didn't flag the file for a crc hash. 
 
 

 
This should not occur in the future, but if it does, then please let me know, right away. 

Remeasure the pool (Pool Options -> Remeasure).
 
Depends on a number of factors.
 
If the PoolPart folder is not hidden, then it has been removed from a pool, and is considered "not pooled".   
 
And in this case, if there is data in this folder, then it will show up as other data.
 
 
To be honest here, I think the best solution will be to move all of the data out of both of the poolPart folders on this disk, delete the folder, reboot the system and then re-add the disk to the pool.  And then move the contents into the newly created PoolPart folder and remeasure. 
 
If you have issues with deleting, then do this;:
http://wiki.covecube.com/StableBit_DrivePool_Q5510455
 
 
Also, I think you opened a ticket that involved this.  
We can see about opening a remote support session so I can take a look at what is going on directly and help out. 

Right now, there isn't anything we can here. 
 
Specifically, because the drives are all in RAID arrays, we don't see the actual, underlying disk.  We only see the RAID array.  This means that the controller itself is not passing on the SMART data properly.
 
HD Sentinel works by querying the controller directly and grabbing the information from there. This is why the software may be slow and buggy, actually. 
 
 
The best suggestion I can really give you is to grab a SAS 9200-8e or 9207-8e card instead. These are HBA cards, so no RAID support at all, but they pass on all of the SMART data properly. 
 
 
 
Otherwise, the SMART data may not be strictly necessary. The file system and surface scans may be able to detect issues prior to failure. 

Drive is already added to the pool. 
 
Yeah, this is a known issue with the release version.  Resetting the settings will fix this issue, actually. 
But this is something that shouldn't happen on newer builds. 
 
http://wiki.covecube.com/StableBit_DrivePool_Q2299585B

There isn't really a work around for this. 
 
Specifically, even if you're using x2 for the "pool file duplication" to enable duplication on the entire disk, we can't be 100% certain of that. 
 
You could have different levels of duplication on the pool. 
 
We could "fix" this by running some calculations each time that the free space was queried.  But that would be essentially checking the duplication status of the ENTIRE pool every time.  Which would add significant overhead.  Or even cache it and look for changes. 
And then there is the said calculations, which would also add overhead.
 
The simplest method is to report the combined free space of all of the drives.   This is the simplest and most compatible method to calculate the free space. 

Desani,
 
Is this still occurring? 
 
If so, could you grade to the latest and see if this helps? 
http://dl.covecube.com/CloudDriveWindows/beta/download/StableBit.CloudDrive_1.0.0.842_x64_BETA.exe
 
If that doesn't help, let me know. 
 
 
https://stablebit.com/Admin/IssueAnalysis/27363

Alex confirmed which: 
 
The files are removed from the disk with the lease free space, first.
 
So if you're trying to free up space, this may be the specific type of behavior you want. 

The problem isn't just "yanking out the drive".
 
The main problem is that USB is inherently, and allowed to be flaky.  The drive can (will) periodically spontaneously disconnect form the system, and that is a serious issue. 
Ever had a USB drive plugged in and heard the disconnect and then reconnect chimes in rapid succession?  That's what I'm talking about.  This is rather common and actually PERMITTED by the USB specification. 
 
The problem is that if this happens while writing to the cache, the only thing we can do (that won't guarantee corrupt, basically) is to BSOD.   And BSODing every time the USB drive disconnects? That's .. really not good for system stability, in general. 
 
There is a request to add this ability, anyways, but it would be an advanced setting, at best. And even then, we're still not sure it's a good idea.
 
That said, if you don't mind hacky solutions, you could create a VHD file, store it on the USB drive, mount it and then use that for the cache.  I'm not even sure that would work, though. 

That is absolutely understandable.  I wouldn't want to pay for software that is being abandoned either.
 
That said, we have ABSOLUTELY NO INTENTION OF ABANDONING ANY OF OUR SOFTWARE. 
 
We do apologize for the extreme delay in releases here.  Unfortunately, this is heavily due to StableBit cloudDrive being signfiicantly more complex than we anticipated (the initial public beta was build 240, we're on 834....).   Additionally, we are a small company, and Alex is the only developer at this point.  
 
So for the most part, his effort has been focused on StableBit CloudDrive.  This means that StableBit DrivePool and StableBit Scanner have suffered, in that they haven't gotten much attention (bug fixes). 
 
We know that this isn't good for us or our products, and it leaves things in ... well, a mess.  
 
Once StableBit CloudDrive has a stable release, things will "get better".  After this happens, Alex plans on going through all of the pending issues for both products, and then pushing a public beta and then stable release for those products. 
After that, we have plans on streamlining the development and testing process so that we can have periodic "scheduled" public releases, that are not dependant on Alex's workflow.  So that this never happens again. 
 
And trust me, we are not happy about how things have progressed ourselves... but drastically changing this right now isn't good either, as it could significantly delay a release for StableBit CloudDrive, and it's already been in beta "too long" for us. 
 
 
Additionally, the internal beta builds are very stable, and should be safe to use for production use (myself and many others do). 
 
Further, I have written a "known issues" post, that you can check to see if you want/need to upgrade to a beta build:
http://community.covecube.com/index.php?/topic/1206-stablebit-drivepool-known-issues-and-limitations/
 
 
Yeah, I apologize for that.  Between being swamped by the latest CloudDrive (Google Drive specific) issue, and personal issues (medical and mental stuff), I haven't checked the forums as much as I would like, or should. 
 
 
 
@Spider99, not ignoring you, but I've already referenced/answered what you've said above. 
 
 
This is something that Alex and I have talked about at length, and repeatedly.   
 
So it's something that is DEFINITELY on our minds.  As well, it should be. 
 
There are a number of "solutions" here that we can implement to ensure that we remain afloat.  
Time/version limited licenses (as you've mentioned). Releasing new products periodically to keep revenue up (we have several additional products/services planned already) Release a subscription based product (service), for reliable income. Switch to paid support solutions  
Each one of these options has their pros and cons, and none are mutually exclusive (we could do all of the above).   These are all options that we've discussed internally, and at length.  
 
To be honest, neither Alex nor I are found of the "time/version limited licenses", and prefer to stick to a lifetime license solution. It's a much better experience for users, as it produces less confusion.  And basically it's too late to switch our licensing scheme for existing products (or we'd have to grandfather everyone in).   
 
And as I said, we have several products planned for release already. StableBit CloudDrive is technically included in that, for now. But we have several other products/services planned. Specifically, StableBit FileVault, StableBit Cloud, StableBit PowerGrid and StableBit.me.   These are all additional products/services that will fit in neatly with our existing products, and should provide additional revenue for us.  You can read a bit about these here:
http://wiki.covecube.com/Development_Status
 
(personally, I've been pushing hard for StableBit FileVault for a while now, as it may really address the "bitrot protection" feature that many people want)
 
 
As for ongoing revenue stream, services are .. well, the best option for that. A monthly or yearly payment means continuous revenue stream, as well as offset the price for such a service.  And that would likely be what StableBit Cloud is.  It would not (may not) be self hosted, but we hope that what it does offer would be more than worth it for those interested. 
 
 
 
And as for the paid support, this has been the topic that has been the most heavily debated.  To put this bluntly, even though this is what would directly affect me (paid support, means more money for me directly), I am very much opposed to this.  Other products (competitors) do implement this, and in some cases, I can absolutely understand why ...  I do not like (rather, I hate) the idea of a paywall between customers and good service.   Good tech support is something that should be part of the intrinsic price of the product, not a hidden cost. 
 
However, there are circumstances that I do agree would warrant that paywall.  Such as immediate support (within the hour), remote support to help set up things, etc. 
 
 
 
So, as you can see, this is something that is definitely "on our minds". And it does come up often.  
And this is by far not a complete list of potential actions we can take. It's just the primary ones that we've discussed. 
 
 
@anotherforumname:  I hope this assuages your fears about our software becoming abandonware. Both from an update standpoint, and from a financial one, as well. 
 
 
If you have any more questions, don't hesitate to ask. 

sorry for the delay.
 
For the SSD Optimizer, it should work fine on newer versions (I'm on the "bleeding edge" with my system, and it works fine). 
 
Specifically make sure it's enabled.  CLick on "Pool Options" -> Balancing.   Open the "Balancers" tab, and make sure that "SSD Optimizer" is enabled, and uncheck all of the other.
ALso, select this specific balancer and make sure that SSD drives are checked as SSDs (this isn't set automatically).

Yes and no.
 
Specifically, each pool as a unique ID generated for it.  If the pool ID's don't match, they're part of separate pools.
 
So if you connect a second set of pooled disks to the system, it will create a second pool drive, automatically. 

Yay network discovery....
 
This can happen, and it tends to be a router/switch/network config issue.
 
That said, yo ucan manually specify "peers" on each device to force them to show up:
http://wiki.covecube.com/StableBit_DrivePool_2.x_Advanced_Settings#RemoteControl.xml

Like a champ.
 
 
That said, it sounds like you want more technical details. 
 
If real time duplication is enabled, the file is written to both disks, and is locked on both disks.  This specifically bypasses any issues with file locks.  
 
Now, regardless of real time duplication, modifications are done to all copies of the files, also bypassing this issue. 
 
 
Alex and I have ran VMs off of the pool without issues.  I store my OutLook PSTs on my pool, as well.  So, this is a well tested feature. 

This happens if there are too many errors.   This is specifically to prevent these errors from locking up the system (which absolutely can happen). 
 
 
 
That would definitely cause the issue.

Nope, not really.  
 
 
That and the full product name is "StableBit CloudDrive". "StableBit" isn't actually the company name. That's Covecube. 
 
 
 
Also, it appears that Amazon is trying to rebrand to "Amazon Drive" rather than Amazon Cloud Drive.  So rebranding our product wouldn't really help in the long run, either.

Yes, absolutely.
 
The only difference between the trial and retail license is that the trial ends. 
 
When the trial license expires, the upload speeds are severely throttled, but you can still download at full speed, so you can move the files off of the drive. 
 
http://stablebit.com/Support/CloudDrive/Licensing
 
 
So, really all you need to do here, is detach the drive, and then attach it on the new system. No issues, no problem, no hassle.

If real time duplication is disabled, then it depends on the file. And what you're doing.
If the file is already duplicated, then any modification to the file is done in parallel to all copy of the files.  This includes writing to the file or moving them around Newly created files are not duplicated, until a duplication pass occurs (IIRC, 1AM, daily).  If you're reading the file, then this is handled "normally". If read striping is enabled, then it depends on ... well, more factors.
 
Additionally, when duplicating the file, IIRC, we do set the modify time to be the same.
Specifically, if there are multiple files, during a duplication pass or when accessing the file, we check the modified time. If that doesn't match, we may check the CRC of the file.  If that doesn't match, then we flag the user for a duplication mismatch... otherwise, we update the info on both files to match the newest file.
 
(IIRC, I'm not 100% sure about that)
 
 
As for the Alternate data stream, I'm not sure.  However, I do believe that yes, it would get duplicated to both disks (as ADS are just a special file type, essentially). 

No.  It will copy the entire file to the other disk.  However, that file may get dedup-ed in the same way.
 
The issue here, is how deduplication and our software works.  And this is part of why the beta vesion is "required", or you need to enable an advanced option.
 
Normally, our software bypasses all file system filters when accessing the underlying data.  This is boost performance (filters can cause serious slow down), and for compatibility (some filters freak out when the same file is being accessed repeatedly, and when one request isn't finished yet.... I'm looking at you, Avast). 
 
This is fine, usually.  However, the deduplication feature splits the contents. It creates a special reparse point out of the original file. It leaves non-redundant data attached to this file/reparse point hybrid object, and it puts all of the duplicate data into the "System Volume Information" folder (that same one used by VSS).   
 
Then when accessing files, it uses a file system filter to splice this data back together, in the right order. 
 
 
Now, as to why this is an issue:
Deduplication can't access the blocks of data on the Pool drive. So it just doesn't work.  StableBit DrivePool bypasses the file system filters on pooled disks, so you would only get partial (or no) data when accessing deduplicated data.   This is why you MUST disable the "bypass" option.  This way, the dedup filter can splice the data back together, properly.   
The beta version looks for the "dedup" filter, and automatically disables this "bypass file system filter" option on the pool, to prevent this from being an issue.
Additionally, the latest internal betas include some special handling when measuring the drive. 
 
 
Also, when balancing or duplicating the data, it will grab the spliced together data, as well.

Well, you can mark them as scanned, manually.
http://stablebit.com/Support/Scanner/2.X/Manual?Section=Disk%20Scanning%20Panel
 
But yeah, that would be something nice to include, and is something that we are definitely thinking about. 

http://community.covecube.com/index.php?/topic/1226-how-can-i-use-stablebit-drivepool-with-stablebit-clouddrive/
 
 
Unfortuantely, there isn't a good way to do this right now.  

You can set the "Drive Usage Limiter" to only have duplicated data on the CloudDrive disk.  Since it needs 2 valid disks, it WILL use this drive first, and then it will find a second drive for this as well.
 
For x3 duplication, that will store one copy on the CloudDrive disk, and 2 on the local disks. 
 
However, this degrades the pool condition, because the balancer settings have been "violated" (duplicated data on drives not marked for duplication). 
 
 
 
 
However, we do plan on adding "duplication grouping" to handle this seamlessly. But there is no ETA on that.