Christopher (Drashna)

Sorry if I missed anything, but you guys have been busy today! The reason that duplication may be taking a LONG time is simple: We are not using the normal priority to copy the files. This means that you're not going to see the normal speeds of a file copy. Specifically, we use a background priority to move files around. For duplication and balancing. That means this can take significantly longer if you have a LOT of files. However, you can check C:\ProgramData\StableBit DrivePool\Service\Logs\Service" for the log files and see if it's hanging up on any specific files. It could be erroring out a lot. Especially considering all those SMART warnings. Also, depending on what the SMART status on those drives indicate, that could be a factor as to why it is taking so long. If the disks are not in good health, it could cause the file operations to take longer (I've experienced that myself, on certain types of SMART errors. And yes, if the disk is marked as damaged (bad/unreadable sectors), DrivePool will actively move data off the disk and avoid using it. I personally recommend going a step farther and using the StableBit Scanner balancer to force DrivePool to evacuate unduplicated data off of any disk with SMART warnings. Leaving duplicated data may be fine though.... However, if you're okay with tweaking files to maximize performance, then you may want to take a look at the post here: http://community.covecube.com/index.php?/topic/574-optimal-advanced-settings/&do=findComment&comment=3516

To clarify (and make it simple to find), here is Alex's official definition of that "Other" space:

That looks like a data base issue, and is unusual. If it happens again, let us know. Also, feel free to PM me a dropbox/box.com/google drive link with the contents of the "C:\ProgramData\StableBit Scanner\Service\ErrorReports" folder.

It's probably not just that DrivePool is using the disks. I've used chkdsk on drives that are in the pool without much issue before. The best way would be like umfriend has recommended, and that's scheduling a scan at the next boot. However, if you don't wish to do this, then you can manually run the command to force it. If you know the volume letter in question, you can run "chkdsk z: /f /x", where "z:" is the drive in question. The "/f" forces it to fix the normal issues, while "/x" forces the system to dismount the volume first, preventing access to the drive. This will likely cause the Pool to show a missing disk, as well as be set to a read only state because of this.

What version of Scanner are you using? If it's the "release" version, could you download the latest internal beta build, and see if that works better? http://dl.covecube.com/ScannerWindows/beta/download/ And make sure you grab the "EXE" version.

Yeah, Scanner will throttle or pause based on activity. And not just activity on the disk, but on the controller as well. This is to help prevent any sort of performance issues from occurring.

Well, if you have Real Time duplication enabled, then the writes are done in parallel. I beleive that the slower drive would slow down any transfer or access. So if this is an important consideration, then you may want to check out the Archive Optimizer optional Balancer, as this lets you specify feeder disks. These disks are written to first, and then later moved off of the pool. For read access, if one disk is significantly slower, we'll read from just the faster disk, to speed up access. However, if they're close to the same speed, we'll use a technique called "Read Striping". It's basically what it sounds like. We read ahead from both disks, and cache the contents, to speed up access. http://stablebit.com/Support/DrivePool/2.X/Manual?Section=Performance%20Options

I'm glad to hear it. I wasn't sure if you had purchased StableBit Scanner already, so I wanted to make sure you were aware of the option. And to set that information, you'll need to right click on a disk and select "Disk Settings". There are a number of other things you can set here, but the two options I'm talking about are at the bottom.

Well, I'm glad to hear that you've figured out the issue! As for the "unknown" space, sometimes the measuring information gets corrupted. Resetting the settings, also resets that information and forces DrivePool to remeasure the pool.

It's used by "Volume Shadowcopy Service" and anything that uses that feature. That includes Windows (Server) Backup, Previous Versions, System Restore, Azure Cloud Backup, Acronis, etc. If you're not using ANY of those utilites, then it is 100% safe to purge those snapshots. Could you post a picture of what you mean? I just want to be 100% clear, and an image would be much simpler. Also, since I can't tell, what version of DrivePool are you on (1.3, obviously, but more specific than that)? That, or if you wanted to see about updating to the latest version of DrivePool? http://dl.covecube.com/DrivePool/beta/download/ (Newest at the bottom)

Oh, I definitely understand that. But from a management/customer service standpoint, it's less than ideal for us. Which is why I replied to it with what I did. I wanted to make sure that anyone seeing it knew that the issue had been addressed. Also, if/when the issue gets sorted out, I will try to make sure the solution is posted here as well (if you don't beat me to it). Worst case, I try to remember every issue I encounter (be it mine or a customers) and use that to help troubleshoot issues in the future.

DrivePool will recognize the drive, regardless of it's location and letter. So relocating the drives shouldn't be an issue at all. As for identifying the drives... well, I have a Norco 4220 as well, and yeah, it can be troublesome. However, you can mount the disks to folders, which may help: http://wiki.covecube.com/StableBit_DrivePool_Q4822624 Additionally, In StableBit Scanner, you can specify a "Case" and "Bay". This information is actually displayed in DrivePool as well, if both products are installed on the system. I use this option to label each "rail" (or row) in the box as a case (eg, Rail 1, Rail 2, etc) and then label the bays as 1-4, for each. That makes identification super easy. And you can "group by case" in Scanner, for even easier visual separation.

By "snapshots", I mean "VSS snapshots", or "Shadow Copy snapshots". http://www.symantec.com/business/support/index?page=content&id=TECH83223 But I'm not sure you can easily do that on WHS2011.... Could you get a memory dump of the service? http://wiki.covecube.com/StableBit_DrivePool_Service_Memory_Dump After doing that, upload any error reports and logs. http://wiki.covecube.com/StableBit_DrivePool_Log_Collection Namely, do Steps #7-10. After doign that, reset DrivePool's setttings, and that may fix it: http://wiki.covecube.com/StableBit_DrivePool_Q2299585

Since you've posted this in a ticket already, I'm not going to try to answer it here, because there is a lot more data there. However, the entire issue is definitely a very odd one, as you've described it. And hopefully, we can get it sorted out.

Yeah, currently StableBit DrivePool does not support adding networked locations to the Pool. Only physical disks. The except to this may be iSCSI, as these show up as physical disks to Windows, and therefor to us. As for VMWare, if performance is important, then you will be better off with RAID, I think.

This is all an in place upgrade, right? If so..... that may not be the best idea. If possible, a clean install is almost always better. Unfortunately. You can use the "Windows Easy Transfer Wizard" to migrate a lot of the settings over from the old install. As for dealing with the computer monitoring error, check the Event Viewer (specifically the Application logs, but system as well), Additionally, there are a bunch of logs in "C:\ProgramData\Microsoft\Windows Server\Logs\". Also, see about changing the workgroup on the computer to match the server's "domain name" (drop the ".local" part, basically). That may help as well.

Have you tried remeasuring the drive? See that option at the bottom for the drive list, next to "Balancing"? Do that, and see if it fixes the "other" issue. Also make sure there is nothing else on K:\, in the recycle bin, or "snapshots".

..... I don't even know what to say to that. Other than maybe I grabbed the wrong logs? But I'm certain I didn't. That depends on how the drive is failing. If it's failing mechanicially, then yes, it should. Okay, could you open a ticket for this then. It will make it easier to track for us, I think.

For the balancing ratio slider, higher is better. That means it is more sensitive to anything being "out of place". 100% means that it will always try to balance, right away. In theory. As for the the amount, I've flagged it for alex. To have a "any amount of data" option, instead of minimum of 1GB. But then again, 1GB is pretty small, all things considered. https://stablebit.com/Admin/IssueAnalysis/2167

That may be a limitation of the Seagate firmware. I've noticed the same on my ST3000DM000's (desktop drives). I don't have a NAS one yet, that I've tested thoroughly. So it sounds like if you want this option, WD Red may be the better choice.

Okay, Alex has taken a close look at the logs, and .... I'll just copy and paste the response here:

NAS drives. Without hesitation. Specifically Seagate NAS or WD Red drives. You're preference. They're meant to be lower powered, without sacrificing performance, or your pocketbook. Though, if you're willing to drop a LOT of money, the enterprise drives aren't bad, and they have a 5 year warranty usually (as opposed to 1-3 years). But I would recommend avoiding the WD Green or Seagate LP drives. The performance on both are pretty horrible, in my personal experience.

That's a good question. I'm not 100% sure about this, but I do believe that when you remove the disk from the pool, it actively checks for duplicates, and changes how it removes the file from the disk in question. So it may duplicate the files as the disk was being removed. But as I said, I'm not completely sure.

You're still experiencing this in 2.1.0.486? If so, then yes, please upload the additional dumps. The issue that caused the first dump was fixed in theory, but either it wasn't, or there was another issue here. So more dumps, means we can see what's going on better. Also, If you hadn't already, could you run a memory test, just in case it's not specifically an issue with DrivePool?

You are very welcome. If you have any other questions, don't hesitate to ask. Regards