Christopher (Drashna)

If that's the case, then whatever broke DrivePool previously in Windows 10 has been fixed in later builds.

Jason, Thank you for sending the logs. Could you grab ALL of the logs, and zip them up instead? This way, I can get a better look. Sometimes, the errors can be hidden and hard to find, if you don't know what you're looking for?

The SMART Queries from StableBit Scanner could wake the drive. That can be throttled in the "Scanner Settings" section. (either by how often or only during the "work window" for the scans. Also, outside of the trial period, it won't scan the disks (which will definitely wake the drives) As for the trial extension, it's to a specific date instead of "an extra X days". So it most likely won't work to extend it now. Contact us at "https://stablebit.com/Contact" if you need to extend it.

Not easily. IIRC, you can do so using WMI... but you'd need to use a WMI explorer, or become very literate in WMIC commands.

you have already opened a ticket for this issue, and I have answered it there. However, could you run "cmd /k mountvol" and post the results?

The folder needs more than just the name, and that's part of the problem. However, could you mind detailing exactly what you did to your system? that way, others with your issue could use this thread as reference?

Do your balancer settings match where is here: http://stablebit.com/Support/DrivePool/2.X/Manual?Section=Balancing%20Settings Also, if you check the "never allow files to be placed on other drives" option, this may force the pool to rebalance the data.

If the dashboard is not loading .. the could you grab the logs from "C:\ProgramData\Microsoft\Windows Server\Logs" Additionally, under the "options" in the dashboard login, there should be a checkbox to "allow me to select which add-ins to load". You can disable the DrivePool "add-in" for now. This will let you launch the dashboard. And you can re-enabled it later, the same way.

Well, usually SFC /scannow doens't come back with issues, and usually it's able to fix them. The DISM command is usually a "last resort" option, used right before reinstalling ... if it doesn't fix the issue.

Try looking at the logs in "C:\ProgramData\Microsoft\Windows Server\Logs". Check the dashboard log, and ... maybe some of the storage ones. If you want, send ALL of the logs from that folder to me (either at drashna@live.com or christopher@covecube.com) and I'll take a look at them. I suspect that this isn't a DrivePool related issue... but just in case: http://wiki.covecube.com/StableBit_DrivePool_2.x_Log_Collection Enable the logging and try to reproduce the issues.

Ouch, I'm sorry to hear that! Well, at least the Seagate NAS drives run very quiet! (at least that's what I'm assuming the comment means ) Also, if the HGST NAS drives are anything like the WD Reds (as they're owned by the same company, WDC), then the Seagate NAS drives will probably perform better, over all.

Pending reboot. That's what the error indicates. Reboot the system, and reinstall. If that doesn't work... uninstall, reboot, install, reboot.

Ummm.... That's the only change from the 601 build. the last Stable/release build was 561. There have been a LOT of changes: http://dl.covecube.com/DrivePoolWindows/beta/download/changes.txt

When a drive is removed from the pool, or even after it's been missing, we actually automatically run a consistency check. If we find files that need to be duplicated (or unduplicated), then we will queue a duplication pass to occur. Additionally (IIRC), the driver can trigger a check if it notices issues with files. If the files mismatch, or are not duplicated, it will trigger a pass as well. Resetting the settings will also trigger this (but that's not a good solution). Changing the duplication status of the pool or a folder on it will also trigger this. All in all, the duplication code is meant to be very robust so that you don't ever need to manually trigger a pass.

We have not officially checked because the OS is still in a state of flux. Initially, it was compatible, but one of the recent updates broke the compatibility. So I'm not sure if it will work with newest OS yet. Once Windows 10 has hit RC or RTM, we will do some heavy testing to make sure that DrivePool is compatible. But until then, we would recommend against it.

Newest build should fix this issue. Specifically, it looks like a problem with the program itself, and not the pool... It was seeing alternate data streams on the root directory and freaking out. Since we host some information there... it was causing the issue. http://dl.covecube.com/DrivePoolWindows/beta/download/StableBit.DrivePool_2.2.0.602_x64_BETA.exe http://dl.covecube.com/DrivePoolWindows/beta/download/StableBit.DrivePool_2.2.0.602_x86_BETA.exe

The only way to accomplish what you want would probably be the "Ordered File Placement" balancer, which fills one (or two, with duplication) drives at a time. This way, it will use all available drives until then.

Sorry for not getting back to you sooner! What you describe is normal. We use some hidden metadata to help identify the pool parts. That's why you're seeing the seperate pool. Try removing the contents from the pool (move the files form the "Poolpart" folder, into the root of the drive). Then, delete the (now empty) PoolPart.xxxx folder. Add the disk to the pool, and then try renaming the PoolPart folder to the original name, and move the contents back into the pool.. The other method to "fix" this is ... well, requires writing Alternate Data Streams, and I'm not exactly sure how to do that (alex, the developer may, but the above process should ... well do that effectively, anyways). Regards

Then it was likely an issue with Scanner getting wrong information from the "VDS" service (which tends to be not 100% reliable/stable). Either way, I'm glad to hear that it's getting the correct information now.

The fact that SFC found some corrupted files and were unable to fix them.... this is more than likely the cause of the issues that you were seeing. In the future, if this fails again, then you should be able to run "dism.exe /online /cleanup-image /restore" to fix the image (this downloads the replacement files from Windows Update, IIRC). But regardless, I'm glad to hear that you've resolved/fixed the issue. If you need anything else or have any questions, don't hesitate to ask. Regards

No need to disable the pool. You can disconnect the drives as needed. The drives that are not connected will show up as "missing" until it's re-connected. DrivePool will detect the reconnect (give it a minute or two, it may take a bit), and it will show back up in the pool. In the meanwhile, the pool will be put into a read only state until the drive issue is resolved.

To clarify, The drives were offline at the time that DrivePool was looking for the poolparts to add. This really shouldn't happen, and they do so up "eventuall". However, that it's causing the shares to disappear is .... unusual as well. Normally, once you've restarted the service, the shares will come back. But if they're completely gone, ... something is going wrong. In this case, could you run "fsmgmt.msc" after a boot and see if it lists any shares in the "Shares" section. If it's not .... then I would recommend running "sfc /scannow" on the system. Also, do you have any antivirus loaded on the system?

For the specific BSOD that you had, yes, that will take care of the issue. Alex (the developer) that the issue I have listed above is the same issue as what you saw.

Was this from the prompt in StableBit Scanner? If so, the URL is using properly setup to use HTTPS. Could you post the specific URL in question, so we can make sure?

Well, we definitely got the upload this time. As for the cause of the BSOD, please do install the beta version. The issue causing it is fixed in the build that I linked you. Specifically, this issue: [D] [issue #13504] Optimized some spin lock code that was causing a DPC_WATCHDOG_VIOLATION on Windows 8+ in one reported case.