Christopher (Drashna)

These are two different disks? From the looks if it, they are, but I can't tell for sure. However, at the bottom of the SMART info screen (any disk), could you check the "Submit to Bitflock" checkbox and either open a ticket (http://stablebit.com/Contact) or PM me the BitFlock ID, and we'll see if we can fix the issue.

From the looks of it, yes. It depends though. If the clock speed is below 2GHz, then yes, definitely. If it's above ... then it depends, but probably not. Thank you for uploading the folder. And i completely understand. I've seem similar behavior on my system, but it's mostly gone away (I .... live on the edge and generally run the newest build). But hopefully, the issue is easy to identify and fix. But given the nature, I doubt it. Also, to make sure, none of the constituent disks exhibit the same issue, correct?

Alex is currently working on reproducing the issue, so we can isolate it and fix it. The reason it's taken a while is that he was fixing a nasty issue with HyperV and how it locks file. Fixed that last week, and has been working on this issue for the rest of it and this week.

We'll have to look into this. If you could enable tracing and duplicate the issue? http://wiki.covecube.com/StableBit_DrivePool_2.x_Log_Collection However, if the Azure backing hooks into VSS (volume shadowcopy) which I suspect it does, then that would be why it is failing on the pool and not the other disks. This would be the same reason that Windows Server Backup fails on it. There is almost no documentation at all on how to support VSS on a file system level. We would like to support it, but it won't be a minor task.

Okay, I just wanted to make sure that you had. Also, have you tried resetting DrivePool's settings? http://wiki.covecube.com/StableBit_DrivePool_Q2299585B

The Yellowish color usually indicates that the disk is a Dynamic Disk. Unfortuantely, we do not support these currently. You need to convert the disk back to a basic disk. This usually requires deleting the partition and re-creating it. If you have any data on the disk, you'd need to move it off of the drive first, obviously.

If it's a lower powered CPU, yes. If it's not, I'd recommend trying it anyways.

Russian section has been added to the translate site. Please feel free to head over and fill in the information.

Try rebooting the system. See if that helps. If it doesn't, and is still having issues, then it may be a bit more complicated to fix. In this case, could you do this: http://wiki.covecube.com/StableBit_DrivePool_Log_Collection

Well, could you do this: http://wiki.covecube.com/StableBit_DrivePool_2.x_Log_Collection And do you have "Network IO Boost" enabled on DrivePool? And do you have any other disk tools installed on the system (such as Acronis)?

Okay, I had forgotten about that (my memory has never been great...) But I'll see if I can duplicate the issue. But if you could get a memory dump when this happens, it would be greatly appreciated. Memory leaks are never good, and we want to prevent them whenever possible.

More data is always good for troubleshooting. And pictures can definitely help us see what exactly is happening.

That, or the VSS filter was doing something weird and causing issues with how we get the info. We will definitely have to look into this. And to make sure, you were backing up the drives in the pool, correct?

If you are experiencing a memory leak via the dashboard specifically because of our products, do let us know. But unfortunately... the dashboard is very bloated on a stock system, and tends to leak memory like crazy. That's part of why 2.X doesn't use the dashboard as the primary UI. Specifically, the issue is that each and every tab is a separate DLL, and some of the "sub tabs" are also different DLLs. As are some of the random other links and sections. So when you load the dashboard, it loads the main EXE file, and then a large list of other files. This can easily cause issues, and seems to usually do so. I'm not saying that we aren't the cause here, or contributing to it... but I've seen this on all sorts of systems. WHS2011, SBS2011E, Server 2012 Essentials, Server 2012 Standard with Essentials Experience, and Server 2012R2 Essentials. With and without our products installed. But if you're definitely seeing higher usage with our products used, a memory dump of the offending product is very useful for us. Also, disabling specific Add-Ins can help identify the issue (by using the "safe mode" option on the dashboard to disable certain add-ins).

A full format (not quick) should do this as well. As well as diskpart's "clean all" (this sets the disk pack to an uninitialized state, and writes zeros to the entire disk.

CHKDSK doesn't always fix the issues, unfortunately. IMO, a "two pass" is excessive. The normal format process, when you don't specify /q (or "quick format" option), it does a full pass once. And actually, the /p:x switch is for ADDITIONAL passes. So /p:2 means that it "zero-ed" three different times. But regardless, I'm glad to hear that it fixed your issue. Hopefully no more issues with the disk.

Sorry for the delay in response here. I wasn't entirely sure how to answer here. Rather, I had a good idea, but I wanted to wait til I was more awake and alert. And to give myself time to think about it. I'm not sure why why it would be displaying these drives differently. In fact, from what you describe, it should not be. Could you open a ticket at https://stablebit.com/Contact ? And get a dump of the DrivePool.UI.exe (if you load that) or the "Dashboard.exe" (as you have that open). As well as the DrivePool.Service.exe process. http://wiki.covecube.com/StableBit_DrivePool_Dashboard_Freeze http://wiki.covecube.com/StableBit_DrivePool_Service_Memory_Dump

You are very welcome. I try to check the forums every day (after answering tickets). I answered this in your other thread. but to quickly summarize: To "fix" the sectors, you need to FULL format or you need to run the chkdsk /r After this, it should clear up the damaged/bad sectors on Scanner. You can (and may want to) verify the location of these sectors on the disk map in Scanner. If the sectors are "uncorrectable" and are not being fixed by format/chkdsk.... there is basically two options: -Toss the disk (or pull it apart and have fun), or -Run a utility such as SpinRite (~$60, IIRC). SpinRite is an "offline" (boot disk) utility that does a very very low level scan. This should fix the issue. If not... then see the above line. Or suck it up and keep using it. And yes, you probably have many more remapped sectors. This happens normally during the life of the drive. Usually, it's denoted by the "Reallocated Sector Count" SMART value. You are very welcome.

Thanks! Also, note the Box.com upload widget at the bottom of that linked page. Please use that, as the dump may be excessively large. Also, feel free to compress it ("Send To >> Compressed folder" works fine).

Unfortunately this is basically normal behavior. A quick format will not fix this issue either. That basically just wipes the file allocation table, and starts from scratch (basically empties NTFS's database on the volume, without writing to the actual bits). You'd either need to run a full format (which can take hours, or days), or you need to run "chkdsk x: /r" (where x: is the drive in question). If you're using Windows 8 or server 2012, (or up), you can add "/scan" to the command and continue using the drive as normal. Specifically the reason for this behavior is that a) we never, ever, ever write to a disk (well, except to recover said files, or file system, but only AFTER asking you), and b.) bad sectors are only reallocated when the disk attempts to write to the physical location. When it fails, you get an increase to the "reallocated sector count" setting in SMART, and it actually remaps the damaged sector to a new location on the disk. This last bit (reallocating the sector) means that you cannot ever restore the data from the bad (and now reallocated) sector. This is why we do not right to it. So that you can run recovery software, if you want/need to. Or so we can attempt to read the data (we 20 different "head placement profiles" to attempt to read the data during the recovery attempt. But we write to a different location/disk. The full format writes to the entire disk, and chkdsk /r identifies these bad sectors, and attempts to recovery them... or force the disk to reallocate them.

Adam (?), If this happens again, open the task manager. Check for the "DrivePool.Service.exe". If this process is using up a lot of memory (more than 200MBs), then something is definitely wrong. In this case, get a memory dump of the process and submit it to us. http://wiki.covecube.com/StableBit_DrivePool_Service_Memory_Dump

To each their own. And to be honest, I agree with gtechwi, I like having GUI. Commnand line is nice, but having a GUI... It's important to me.

Yeah, it is. Because it's definitely a "special use case". And we want to keep those separate, just in case. If that doesn't help, or doesn't do what you want, then please do let us know. But I suspect that it maybe just want you were looking for.

Yes, exactly. The "breakout" cable uses a SFF-8087 connection (that's the name... and what's on the card I linked), and then it fans out to 4x normal SATA data connections. And you plug those directly into the drives. For the card I linked, you'd need 2 of these breakout cables, but it would then support 8 drives. You could get much more complicated with expander cards and such... but I just want to keep this simple. (and that's best for RAID solutions). And you shouldn't experience any bottle necking. It's a PCIe v2.0 8x (8 lane) card. Each "lane" gets 500MB/s on 2.0. So that's plenty of bandwidth for the card and drives.

Since this isn't clear, EVERYTHING is set to be duplicated, correct?