Christopher (Drashna)

I'm not 100% sure (Alex will have to answer). But I beleive that is in reference to EFS and not bitlocker. (I've flagged Alex, to verify this) No. We do compare duplicate files when performing he periodic duplication pass to make sure they match, and prompt you if they don't. But we don't maintain a checksum list of all the files. Additionally, we offer additional verification on move/copy for DrivePool. It's off by default because it does increase the overhead (and it can add up real quick). It's the "DrivePool_VerifyAfterCopy" option in the advanced config file: DrivePool v1.X: http://wiki.covecube.com/StableBit_DrivePool_Advanced_Settings DrivePool v2.X: http://wiki.covecube.com/StableBit_DrivePool_2.x_Advanced_Settings I think I answered that in part already. But Scanner's surface scan should help the disk identify problem sectors on the disk, hopefully before anything happens. Or at least by "refreshing" the sector by accessing it help prevents bit rot. Alex talks about StableBit Scanner and how it works in detail here:

Also, it's accessible via "msconfig" .... or "task manager" in Windows 8.

hehehehe.... I laugh because I tease Alex every time he says something "should be simple". Because it NEVER turns out to be simple. Ever. (well maybe sometimes, but usually not). In ten minutes of usage, the driver can get hundreds of thousands of IO requests (this is a guess, TBH, and Alex can post more realistic stats, if inclined). We would have to track each and every single one. And then, we would have to filter through these, figure out which are relevant and which are "junk". And then we have to make sure that none of these requests error out, are canceled or are reversed (which happens, such as in the case of a failed rename/copy/move). And then update the database/cache, on each successful change. You can see how this could cause a serious impact on performance. Both on disk performance but also on memory/processor usage. And this is basically what the NTFS driver does already. But it "flushes" the cache to the disk periodically (and by periodically, this delay is measured in milliseconds or less). In fact, that's what that "memory usage" setting increases. But to a limited degree. So instead of reinventing the wheel from the ground up... we just hook into it, basically, and let 20+ years of development handle that for us. At least, I am pretty sure that is what the "situation" is. Alex is DEFINITELY the expert here. I'm just relaying the situation and information as best as I understand it. He's the one that has written the driver and everything. But I've "pinged" him, so he can either tear apart what I've said, confirm it, or at least provide his point of view.

I've bumped it for Alex, and I'm contact him directly about it. And yeah, we can definitely understand that.

Yeah, that's.... basically expected. It really depends on what the kernel wants to keep cached. And unfortunately there isn't any other settings to use even more memory. As for an internal cache/database.... the issue with that is how do you keep it in sync? You start to introduce a whole lot of issues. Including some of the serious issues that Drive Extender from WHSv1 had... You also start needing a lot more resources and writing to the disk a lot more. And any database can adversely affect performance. We've considered it, but this is the best method, in our opinion. Also, NTFS *is* a database, of sorts. For files. But specifically, why it works sometimes and not others is that it the kernel (I believe) keeps a certain amount of IO activity (that includes LISTING files) in memory. And it "dumps" this out of memory as it feels necessary. the "memoryusage 2" command tells windows that it should use more memory than default. This means that it's more likely to keep this stuff in memory and not cause disk access.

Specifically, you should see stuff added to "C:\ProgramData\StableBit DrivePool\Service\Logs\CoveFS\". But if you could upload the entire folder anyways, just in case. http://wiki.covecube.com/StableBit_DrivePool_2.x_Log_Collection

Well, you can remove it from the "HKLM" Run registry entry. There shouldn't be a big issue doing so. It is mainly for system notifications for the system (such as updates or critical notifications).

I'm glad to hear it!

No, therei s no internal caching for StableBit DrivePool. We maintain no database. That is why it may spin up the drives like this. However, Windows does cache disk access, which would "trickle down" to us. If you have a large amount of memory available on the system, then you may want to consider increasing the memory that the Windows uses for caching: The command is: "fsutil behavior set memoryusage 2" (run from an elevated command prompt, and then reboot). Details about it here: http://technet.microsoft.com/en-us/library/cc785435.aspx

Alex is the one that is the "file system expert" here. However, what I do know is that renaming is probably one of the most tricky file system operations that you can perform. It's complicated and can come back with a lot of issues. As I said before, if you're experiencing ANY issues with the file system like this, then please enable tracing, reproduce the issue, and upload logs. This helps us to identify issues, so that we can fix them. And also, make sure you're using 2.1.0.5xx (any of the "500" builds), if you're using Reparse points.

Well, that may have manually reset the notification then. If it comes back, then please do let us know. That, and I do recommend 2.5 version, as it support email notificatons which .... well, don't disappear and give a more detailed description of what is going on.

you will almost always see some "other" data. I mean no offense, but the post is tagged as "FAQ" for a reason: http://community.covecube.com/index.php?/topic/37-faq-unduplicated-vs-duplicated-vs-other-vs-unusable/ That reason, being that it may not be clear as to why it's "other". But the above link clarifies that.

Thanks. What version of Windows 8 are you using (8.0, 8.1, or 8.1 Update, or the server versions of, and 32 bit or 64 bit)? I've created a request for Alex, so he'll see the tracing logs. https://stablebit.com/Admin/IssueAnalysis/3204

Wonko, Could you update to the newest internal build, and see if the issue persists? http://dl.covecube.com/ScannerWindows/beta/download/ If it does, open the Scanner Settings section, and find the "Show advanced settings" check box. Check it and hit "OK". Then open the "Settings" button again, and select the new "Advanced Settings" box. Find the "Chkdsk" entry in the list, click on it, and then select the "Verbose" option. Repeat this for "Scheduler" Then submit the logs to us (link to the location is in that Advanced Settings window.

Xero, It's not well documented, nor explicitly mentioned in documentation. But yes, this is standard practice, and we recommend it for "seeding" a new pool (aka switching to it). The reason we don't document it really, is because you need to understand the caveats. It's quick, and simple. But you absolutely do need to remeasure the pool. You also need to make sure that the NTFS permissions are "in order". (at the very least, that SYSTEM has full control on everything). And ideally, you will also want to make sure that the StableBit DrivePool service is stopped while doing this, so it doesn't try to duplicate or balance the data. Once it's done, you can start the service and remeasure.

It should tell you what disk in the notification. However, the best way would be to enable email notifications (requires 2.5). That should give you a clear indication of what disk is overheating or causing the alert. Additionally, sometimes the "WMI" method causes false errors. Setting the "Smart_NoWmi" option to "True" in the config file may prevent this behavior: http://wiki.covecube.com/StableBit_Scanner_Advanced_Settings

What exact version/build are you using of StableBit DrivePool? And could you enable tracing on the pool? (gear icon -> troubleshooting -> Enable file system logging) Or do this: http://wiki.covecube.com/StableBit_DrivePool_2.x_Log_Collection

Well, for the most part, Scanner.UI shouldn't be writing to any disk, except the system disk for settings. As for $mft and $logfile, those are internal NTFS metadata. (But I'm guessing you already knew that). Since something is definitely writing to the disks, do you have anything that is running that would be accessing the files? Indexing programs, media programs, disk utilities (such as defraggers or imagers)?

Okay, everything looks "fine", then. Unfortunately. And no, the file placement limiter balancer doesn't swap data out. However, if you want to force DrivePool to migrate more out.... set the slider in the File Placement Limiter balancer to 99% and the one in Balancer Settings to 100%.

And fixed: https://stablebit.com/Admin/IssueAnalysis/3198

Actually, for the balancing settings. The window you have open above, but the "Settings" tab. Sorry for the confusion.

well, that's there in the newest builds... Oops! I've flagged the issue. Should be fixed in the next internal beta

Glad to hear it! And I really do think you'll like it. Just don't forget to get the discount when you buy it. To do so, go to the purchase page (http://stablebit.com/Buy/Scanner) and scroll to the bottom. Input your Activation ID into the box at the bottom and hit the "Apply Activation ID" button. It will refresh the page with the discounted pricing. Regards

Actually, everything looks "proper" there. On the two disks in question, look at the bars in the main UI. Notice how they have the dark blue arrows underneath the bars? That is the "target" for the space used. However, since the other drives are very full, that "Try not to fill a drive above XX%" slider is preventing the disks from evacuating the files off of that drive. DrivePool needs more space, or to move the slider (but even that doesn't look like it will help that much, as most of the drives appear to be over 95% full). But ideally, adding disks would be the best option here. (I know that's not a great recommendation, but you're almost at capacity). Though, from the sounds of it, ideally you want the balancer to forcibly swap where the files are. If so, on the main page, what are the settings that you have there?

That would be definitely something to check. It may make a difference here.