Christopher (Drashna)

That's ... really odd. Could you open a ticket at https://stablebit.com/Contact and then run the StableBit Troubleshooter, using the "DirectI/O" option. http://wiki.covecube.com/StableBit_Troubleshooter

Try running a CHKDSK pass of all the disks in the system. Try remeasuring the pool. If that doesn't help, then you may need to do this: http://wiki.covecube.com/StableBit_DrivePool_Q4142489 If this is with the file system scan (and it sounds like it is), you may want to update to the latest beta, as that has a fix for this issue. http://dl.covecube.com/ScannerWindows/beta/download/StableBit.Scanner_2.5.4.3259_BETA.exe Honestly, I'm not sure. It sounds like you may have accidentally disabled duplication, or removed the drive from the pool.

I've noticed this myself, and unmounting and remounting will fix that. To be honest, I think this is an issue with Apple's implementation of SMB/Samba/CIFS. I'm not sure there is much that can be done. But I'll look into this.

StableBit DrivePool places files on the disk with the most available free space (absolute, not percentage). If that's the case, then the "realtime placement limiter" arrow that you see is absolutely normal. It's trying to clear out the drive, to prevent data loss. If you clear the status and it comes back, then you should definitely consider replacing the drive. Especially if it's under warranty, as you should be able RMA it.

AWESOME!! I'm glad to hear that!!

@dan66215 it uses the disks in the pool to determine free space. Because you have one of the disks that is completely filled, that is likely the issue. Especially if you're using ordered file placement. That said, it may be worth installing the "Drive Space Equalizer" balancer plugin and enabling that. StableBit DrivePool Balancer Plugins

Yeah, it would, and it is something that we've talked about internally. But "complicated" is a bit of an understatement, and it would eat up a lot more bandwidth, etc. We should have a release for it out Very SoonTM

Ouch! sorry to hear about the issues. And yeah, that did sound like a disk issue, and not a pool issue, specifically. Just a heads up, StableBit DrivePool does have a notification option for when there are missing disks. Make sure that's set up. Additionally, for StableBit Scanner, grab the latest beta, as that will fix the issue with the lost settings: http://dl.covecube.com/ScannerWindows/beta/download/StableBit.Scanner_2.5.4.3259_BETA.exe

Oh no, I'm sorry to hear that! That really sucks! If you have a UPS/battery backup, it may help. However, I've heard of it not being enough. Which is not surprising, based on the amount of power that lighting brings down (well, really, up). The best bet is to unplug everything during a storm.

If you're using the latest beta, try using a build before that. We've had several people complaining about similar issues on the newest.

Yeah, as long as the drives show up correctly, then it will maintain the pool. As for the power savings, that entirely depends on the power consumption, both at peak and idle. And to be honest, you probably won't see a lot of power savings. The best way to get that savings is to use large capacity SSDs, which is what data centers do. However, they can be a LOT more expensive.

I think you've opened a ticket for this already. Try uninstalling and reinstalling StableBit DrivePool, and it should fix the issue.

To clarify a few things, here: The "unusable for duplication" is a red herring here. It isn't actually impacting you, one way or another. You can safely ignore it. For the write error, it looks like it is set to write to disk 8, which has very little space left. It's not overflowing to Disk 10, because of the balancing settings (and would only do so for duplicated data). You may need/want to change the disk order in the Ordered File Placement balancer plugin to fix this.

Specifically, "diskpart" is a command line utility that hooks into "VDS", the same way that Disk Management does, and allows a lot of control over the disks. As well as access to more features than Disk Management normally gives you. As for "automount", this setting controls the ... well, automatic mounting of disks on the system. Enabled is the default, but disabled means that any disk without a mount point is not automatically mounted, and therefore, is not accessible until it's mounted.

Just a heads up, even if you do turn on duplication for the drive, it won't duplicate all of the data, automatically. It will only duplicate data that is written to. So you'd need to rewrite the entire contents of the drive to properly duplicate the data. It may be simpler/better to create a new drive with duplication enabled and just move the data over, as much as a pain as that may be.

Could all of you (that haven't) open tickets about this, and then run the StableBit Troubleshooter on the systems in question? http://wiki.covecube.com/StableBit_Troubleshooter

I think you've posted this as a ticket, as well. The "GPT Protective Partition" is wrong. That should be "Primary Partition". So, it is the wrong partition type, which indicates that the partition information may be corrupt. Running TestDisk or the like may be able to fix the issue, but it may not.

To make sure, the poor local transfer is from disk to disk, right? And is from a disk outside of the pool to the pool? And is this large files, or small files? Also, keep in mind, that the EX490 is super old hardware, and the max 4GB of memory may be a limiting factor, here. Also, does the performance issue happen outside of the pool, or only with the pool?

Well, I'm glad to hear that it's fixed, but hardward issues always suck!!

You can clear the status for the unreadable sectors. However, during the next scan, they will likely come back. In this case, there is no way to "clear" the status. Because this isn't a case of "oh, something *may* be wrong, just ignore for now". It means that the system was not able to read from those sectors on the disk, which indicates a critical failure. As in, something failed that SHOULD NOT fail. And that's the point of the surface scan. My recommendation would be to clear out any important data that is on the drive, and RMA it it if it's under warranty, or just outright replace it, if it's not. Aside from that, do a full (non-quick) format of the drive, and rescan the drive, see if that helps. If not, the above.

Right now, no. The way that StableBit CloudDrive was designed prevents this. Though, it has been a heavily requested feature, and it may be something that we add in the future.

I'm sorry to hear about the issues. The Unexpected shutdown would trigger the recovery mode for the drives, which means that it would attempt to upload the entire cache back to the Cloud Provider, since we can't be certain what was modified, and what wasn't. Also, if the drives are being used while this is happening, it would increase the "to upload" data, as well. However, just in case, could you open a ticket at https://stablebit.com/Contact ?

Could you open a ticket for this at https://stablebit.com/Contact ? Also, could you make sure you're on the latest beta versions of StableBit DrivePool and StableBit CloudDrive? http://dl.covecube.com/CloudDriveWindows/release/download/StableBit.CloudDrive_1.1.1.1165_x64_Release.exe http://dl.covecube.com/DrivePoolWindows/beta/download/StableBit.DrivePool_2.2.3.1008_x64_BETA.exe And if this issue persists, is there something in specific that seems to be triggering it? Or is it just random?

NVMe Health information should be present in 2.5.4.3216 and up. Have you tried enabling the "Unsafe DirectIO" option, yet?

I'm sorry to hear that.