Christopher (Drashna)
-
Posts
11568 -
Joined
-
Last visited
-
Days Won
366
Posts posted by Christopher (Drashna)
-
-
Should be fine, provided that the underlying disks can hold the VHD/etc files. Eg, the individual files are placed on the underlying disks.
-
Likely, yeah.
Might be worth decreasing the number of threads, and upping the minimum download size, if you can. See if that helps.
-
This happens when the performance counters gets corrupted. This can be fixed by doing this:
https://wiki.covecube.com/StableBit_DrivePool_Q2150495 -
You opened a ticket about this already (thank you!) andI've replied there, but I'll say this again: this is definitely not normal, and StableBit DrivePool should not format a disk, unless it is uninitialized or unformatted.
-
For this, you'd want to use the DrivePool (F:\).
Just move the data from D: to F:, and then you should be fine.
And no, you won't mess anything up by using E:\. However, you'd want to move the data to the hidden "poolPart.xxx" folder instead of to the root directory on the disk. And then remeasure after the data is moved/copied over. And we don't recommend doing this normally, but for the initial migration process, it should be fine.
Also, if you want to hide the drive letter for the E:\ drive, you can do this:
https://wiki.covecube.com/StableBit_DrivePool_Q4822624 -
The "/e" is a switch for lodctr. It's not the drive letter or anything like that.
Specifically, it's specifying the disk performance counters, "PerfDisk".
And glad to hear it!
-
Do you know what version worked properly for you last?
-
The simplest way to do that would be to have multiple pools, basically.
-
Yes, please open a ticket at https://stablebit.com/Contact
And ideally, attach drive tracing logs of this in action:
https://wiki.covecube.com/StableBit_DrivePool_2.x_Log_CollectionAlso, it's very weird that Windows Defender would do this. as we do test with it. (well, it's hard not to). But issues with BitDefender... don't really surprise me.
Also, in the meanwhile, it may be worth enabling the "bypass file system filters" option, as this should prevent the realtime scanner from being used when the pool reads the data from the underlying drives.
-
How did you copy the data over?
If you copied the "PoolPart" folders directly, then that would cause this sort of behavior. There is some hidden metadata that is stored on the disk, and can't just be copied over. You need to add the disk to the pool, and migrate the data that way.
Worst case, you should be able to do this:
https://wiki.covecube.com/StableBit_DrivePool_F1655While, this guide isn't strictly for your issue, it's close enough that it should work just fine.
-
It is from here, specifically:
Unfortunately, there isn't a simple answer to this, nor a simple solution.
It may help to disable "Previous Versions" on the drives, as this does show up as "other" data.
-
Yeah, the duplication creates multiple copies of the protected files, on other disks in the pool. These are 1:1 copies of the files, and will take up the same amount of space as the original.
-
By chance, was the drive in question formatted as ReFS?
If so, then that may be the problem. Beginning of the year, Microsoft released a patch that causes ReFS volumes on removable storage to not mount. And unfortunately, StableBit CloudDrive mounts the drives as removable drives. If you can get an older install, without this patch, you should be able to access the data, at least.
-
-
Would something like a file on the pool noting that it's read only work here?
-
Awesome, I'm glad to hear it!
-
Shadow Copies is the name for the code/feature that supports Previous Versions, and other features of Windows (such as must backup solutions).
It's not part of StableBit DrivePool.
That said, if you wouldn't mind, I'd like to take a look at your system directly, and poke around. I may be able to identify and fix the issue a lot faster that way.
If you're okay with that, head to https://stablebit.com/Contact and open a ticket. -
The simple option, is you don't. Disable shadow copies, and delete them.
The System Volume Information will continue to come back (it's a hard coded Windows behavior), but that will reduce the usage.
If you run "control system", it's the "System Protection" option. Turn it off and delete them for each disk, in question. -
It means that you may have issues accessing data on the pool through WSL.
Namely, WSLuses a layer between WSL file system and windows for the file system that can cause issues for DrivePool (eg, potentially unsupported commands, etc). And adding support for it is not simple.
-
Specifically, the "SSD Optimizer" uses the "drive is being emptied" option, so can if that option is checked (default), it means that the balancers (SSD Optimizer) won't follow file placement rules for the SSD drives, and will empty them, regardless of the rules.
Unchecking the "unless the drive is being emptied" means that it will always respect the file placement rules.
In both cases, it will still work as a write cache.
-
As mentioned, there is nothing wrong. It's just that the placement means that duplication can't be used for a large portion of the pool.
If you have no plans on using duplication, then you can safely ignore this, and may even want to disable the mentiond "Duplication Space Optimizer" balancer.
-
Try resetting the permissions on the pool:
https://wiki.covecube.com/StableBit_DrivePool_Q5510455 -
Sorry, no, WSL is still not supported.
-
https://dl.covecube.com/DrivePoolBalancingPlugins/SsdOptimizer/Notes.txt
Quote* If you've created file placement rules that are attempting to keep files on drives that are designated as SSDs,
then you should disable the "Unless a drive is being emptied" option, under the "File placement settings" category,
on the "General" tab. Otherwise, your File Placement rules will not be respected by this plugin (because it is
emptying the SSD drives).
Account Activation
in General
Posted
Could you open a ticket at https://stablebit.com/Contact for this issue?