Christopher (Drashna)

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.

Detach the drives, deactivate the license, install on new system, activate the license or trial and attach the drives. 
 
That's it. 
 
And yes, when you go to add a drive, it will list existing drives, and even acknowledge the drive's state (eg, if attached on other systems). 

Sorry, yes, it's just faded out, since it's already complete.
 
Or to quote: 

It entirely depends on the provider.  For each provider, we use a slightly different format, based on that provider. 
 
Specifically, for certain providers (such as Google Drive, Amazon Cloud Drive, etc) we do obfuscate the data. Meaning we do some simple encryption on the data, if you don't enable full drive encryption. 
And by "simple encryption", I mean we use a very simple to "break" encryption, and each file has a NULL byte at the start. This is to prevent the provider from parsing the file and recategorizing it based on the file's header.   
 
For Amazon Cloud Drive, for instance, this should completely block it's ability to identify data from StableBit CloudDrive. 
 
Otherwise, the data is raw disk data, and won't show up as the files on the provider, but chunks of raw disk data.

There shouldn't be any issue with removing the other settings, and only keeping what you need.  The other settings will stay at the default values. 

In theory, the Read Striping feature should handle this on duplicated data. 
 
Additionally, you may want to make sure that directory structures are being pinned on the drive in question (Under "Disk Options" -> "Performance" -> "Pinning"), though these should be enabled by default. 
 
Additionally, adding better handling is something that has been requested, and we've discussed.  And it's definitely something that may help here. 
 
 
Though, as for the versions, I beleive that Alex has changed the handling ofr ACD, so if you wanted to try the 1.0.0.777 build, that may help out.

Yup, you need to detach the drive, and then reattach it.  While reattaching it, you can specify the cache drive.

This happens occasionally, it's not a DrivePool related issue, but a Windows issue.
 
However, the fix is rather simple: 
http://wiki.covecube.com/StableBit_DrivePool_Q2150495

The files reside in a hidden "PoolPart.xxxxx" folder on each disk. 
 
Underneath this folder will mirror what the pool looks like normally.  It may not be complete, depending on what files are on the drive. 

Nope. But it works best if they are.
 
Also, you need a number of SSDs equal to the level of duplication you're using, ideally. 
Otherwise, data may be written to "Archive" drives instead.

Well, flagged either way, so Alex can clean this up (eg, handle better in this case)

It's fixed in the latest build, actually.
 
http://dl.covecube.com/ScannerWindows/beta/download/StableBit.Scanner_2.5.2.3122_BETA.exe
 
http://dl.covecube.com/ScannerWhs2/beta/download/StableBit.Scanner_2.5.2.3122_BETA.wssx
 
Specifically, they changed their API in a way that was not backwards compatible, IIRC.

Do NOT run it with "/scan".
 
While, this option is pretty awesome, it skips a number of checks, include the Volume Bitmap.  You need to run this offline only, meaning without the "/scan" flag. 
 
This is an issue that I ran into myself and it tricked me.  (as well as Alex initially).

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.