Christopher (Drashna)

To make sure, this 3TB drive is in a separate pool, by itself? If so, there isn't exactly a straight forward to do so. Basically move all of the contents out of the hidden PoolPart folder, delete the now empty pool part folder, add the disk to the other pool, and move the contents into the newly created Poolpart folder.

Okay. So, other than on the dashboard, ti seems to work just fine, without any problems? I'm assuming that you've rebooted the system at least once since this issue first appeared.... But could you grab the contents of "C:\ProgramData\Microsoft\Windows Server\Logs" from the server, and upload them... I'd say here, but to

I think you posted a ticket about this as well... If so, is this Windows 10? If so.... unfortunately, Windows 10 is NOT supported currently. We've already had some issues report that DrivePool was completely broken in previous builds (the driver wouldn't load). And I suspect that this issue is ALSO because of some low level change to how things work. We'll still look into it ... but providing a fix may be problematic. Because it may fix it now, but cause it to break even worse later. THis is why running a Tech Preview "in production" is a bad idea. It's in flux, and it's much harder to test for compatibility. This was actually probably due to a rare condition when deleting files. It should be fixed in the internal beta builds.

If you're not able ot create folders... check the licensing status of StableBit DrivePool. Not being able to create folders is a symptop of a licensing issue usually. If you're still having issues.... run "fsmgmt.msc" on the "server", and check to see what user account is ACTUALLY accessing the folder. Also, try doing this: http://wiki.covecube.com/StableBit_DrivePool_2.x_Log_Collection And reproduce the issue, then send the logs to us (ideally via https://stablebit.com/Contact as the logs may contain information about your pool)

Well, I'm glad it hasn't happened again, and it definitely sounds like it was a fluke. hopefully, no more issues.

Ah, yeah, we don't support it "in reverse". So that would cause issues. However, duplication info is stored on the pool, so that should never be affected (unless maybe, if you're having disk issues).

Well, glad to hear you got it sorted, then. We'll take a look at the files later then, just in case there is an issue. If you do decide to re-format, then I recommend using the "64k" allocation unit size for the disks, as this is good for large storage files (such as video). This way, the disk will not get as fragmented to start off with, and you may see better performance on file access (as larger contiguous/sequential access of the files).

Assign a label to the O:\ drive and reboot the system. See if that helps.

The service logs main contain the full path to the file. They're located in "C:\ProgramData\StableBit DrivePool\Service\Logs\Service", and should appear on the day in question. I would recommend opening a ticket at https://stablebit.com/Contact and upload the logs there, as these logs can contain personal information (namely, the paths of the files, and file names) However, the "oplock" error means that something has the file open. A running program, perhaps. Or a service in the background?

Yeah, we fixed that. That's ... pretty much the only change between the 2.1.1.558 version and 2.1.1.561 version, actually. We were getting a LOT of requests for license resets because of how everything was being handled. So .. the 561 version contains some code to check for the 1.X settings and validate them, to make the transition smoother. This means that the installer... well see below. Remove the installed version from teh Dashboard (if that has issues, use the control panel and then double check the dashboard. Reboot the server, to ensure that the driver is completely removed from the system. Install the new version. Reboot to ensure that the background services are started after the Pool has been recreated. Aka: uninstall, reboot, reinstal, reboot. After doing that, you should be up and running and good to go.

Depends on the OS. If it's Windows 8 or Server 2012 (or up), then you can run "chkdsk x: /r /scan". This will run the scan online (it won't unmount the disks, and they'll remain accessible). The caveat, is that it can't always fix issues. You may need to run "chkdsk x: /spotfix" afterwards to take the disk offline and fix it. If you're not using these OS's, then a normal chkdsk pass will be fine. It WILL take the disk offline (unmounts the volume, and prompts you about it). This will cause the disk to show up as "Missing" in DrivePool, which puts the pool into a Read Only mode. Once the scan is done, the disk comes back online, and DrivePool will see this and "reconnect" the missing disk to the pool. And I'm not sure what you mean by the "ready" comment, but I suspect that I may have covered that already. As for chkdsk, /r will take MUCH longer than just /f (and if you have /r, you don't need /f, as it's implied). But the /r is much more thorough and may get issues that just the fix (/f) pass may miss. It's a good idea. Just ...start it before going to bed, and that may help with the timing. And the reason that I'm asking for the disk check here, is that we store the duplication "tags" as hidden NTFS metadata. It is possible that it got corrupted, or was unreadable for some reason. This could change the status in certain circumstances. v2 is much better about this than v1 ... so if you switched versions, that could be the reason you saw this behavior.

Are you using the 2.2.0.606 build. This should address the issue specifically. If you're not using this build, then please update to it and see if it fixes the issue. http://dl.covecube.com/DrivePoolWindows/beta/download/ If you ARE using this build then please let us know.

Well, during the duplciation pass (or during file access), we check the date stamp. If those don't match, we run a file checksum and compare the values (file mismatch errors are reported if they're not the same). This happens automatically, and in the background. This covers both of the issues you've mentioned, at least partially. As for the altered data... it sounds like damage to the disk, or access to the file by something else. Random bit flips and data degradation like that is exceptionally RARE. If it happens, then it's an issue with the disk or the controller (StableBit Scanner has a "Burst test" option which is good for testing this, actually). however, we do have a "duplication audit" tool in the works. It's been well requested, and would be very useful. And Alex (the developer) has added a new notification system to StableBit CloudDrive... and that we are backporting to StableBit DrivePool. This should provide better and more meaningful error reports. Especially in the cases of file issues. Additionally, we have another produce planned, called "StableBit FileSafe". This may cover the other issues you are referring to.

You're very welcome. And you absolutely can change the drive letter with no problems at all! http://wiki.covecube.com/StableBit_DrivePool_Q6811286

Could you run a chkdsk on the disks in the pool? You could upgrade to 2.X and that should handle the potential issue here better. Also, as a last resort, you can create a new folder, enable duplication on that new folder, copy the contents of the old folder in there and then delete the old folder.

Alex has posted a somewhat technical description of why this would be difficult to implement: https://stablebit.com/Admin/IssueAnalysis?Id=14535 But basically, it would require a significant change in the code to implement. We may add this latter, but not right now.

The duplication pass does more than "duplicate" files. It checks the status of the pool and ensure it's set to the proper status. This means that in some cases, that it will delete extra copies, actually. Additionally, yes, we store some metadata on the pool (about reparse points and other stuff). This is x3 duplication, so that is most likely what you're seeing.

The only thing I'd recommend is running Scanner with DrivePool as well. This way, Scanner will run a chkdsk pass (the file system scan) at least once every 30 days. This should help detect issues caused by disconnects. Though, it may be a good idea to schedule a "chkdsk /r" pass periodically, as we only to a "quick scan". Also, if you're using Windows 8, you can use the "/scan" option with CHKDSK to run the scan online (it won't unmount the disks to scan them). As for USB Spindown prevention, well, sort of. We query SMART data often (I think once a minute, by default), and that may prevent spindown/idling. Usually people are asking for the other way around, honestly. If you're having issues with idling, then let us know. I'm sure we can add something to help prevent idling of the drives.

Well, USB can cause the issues with storage spaces as well... however, if the USB connection has been stable for you, then it may work just fine! As for the JMicron, yeah, they're .... weird controllers.

If it didn't email you or redirect you, then it may have retired out. We apologize for that, and will look into the issue With the contact site. In the meanwhile, could you resubmit the logs, or email them to me at Christopher@covecube.com @clonea1: I'm glad to hear that!

Could you do this: http://wiki.covecube.com/StableBit_DrivePool_2.x_Log_Collection But only steps #6-8. After doing that, please reset your settings: http://wiki.covecube.com/StableBit_DrivePool_Q2299585B

It will absolutely auto-detect. In fact, we have at least a couple of users that have done this exact thing, and a few that actually use a "portable pool" as well. However, as for USB (even USB3), I would recommend against it. The drives can, are allowed to (by the USB specs) and WILL periodically suddenly disconnect. For a short term storage, this is fine. But if you're planning on using USB long term, you could end up with issues. These disconnects can cause data corruption (including turning the disk "RAW") As for eSATA, we do highly recommend the ASMedia AMS1061 chipset, as it's the most stable chipset that we've found. Despite descriptions that say they only support 7 disk per port... we've found that to not be accurate (we've had a few users with 8 bay enclosures on these cards).

These internal beta builds are not as well tested, and can introduce new issues. that's why they're not pushed or posted to the main page. However, they may be completely stable.... but they definitely address specific issues. You can see what fixes they include right here: http://dl.covecube.com/DrivePoolWindows/beta/download/changes.txt Where did you send the logs specifically? And if you sent the logs via the contact page, could you let me know what the contact number it generated was? (as I didn't get an email for it and can't find it)

You're very welcome. And yeah, the file placement rules feature is one of the more complicated features. If you haven't already, definitely check out this link: http://stablebit.com/Support/DrivePool/2.X/Manual?Section=File%20Placement

Beaker, could you upload the ENTIRE dashboard log. There is a lot of information, and it can be hard to read if you don't know what you're looking for. If needed, open a ticket at https://stablebit.com/Contact