Christopher (Drashna)

It definitely should be saving the settings. If you're still running into this, please open a ticket at https://stablebit.com/contact so we can get this sorted

Yup. If you mark the bad blocks as unchecked, it will attempt to scan those blocks at the next available time (typically immediately). If the rest of the disk is marked as healthy, it will only scan these blocks (as it only scans sections of the disk that are not checked or haven't been checked in the normal scan window (30 days).

I'm sorry to hear that. Though, does "previous versions" work here? It may be set up by default, and may have instances of the files. It's a long shot, but figured it was worth mentioning, at least. That said, StableBit Cloud should sync this information, as well. I know it dosen't help now, but for the future, it may.

Okay, just wanted to double check. And I have seen and responded to the ticket. Hopefully, we can get this sorted for you!

Buyrak, I sincerely apologize for the issue, and my misunderstanding. Alex has taken over the issue. I'm locking this thread, as there is nothing productive that can come out this thread that hasn't already been addressed (or is in the process of being addressed).

The problem is, that it can cause issues, even when transcoding. And Windows is notoriously sensitive to I/O issues. That said, the SSD may not mark it as unusable until data is written to those specific cells. the only foolproof way to do this is a full format of the drive. I've had this fix the issue for a number of disks, for a while. So that may help here. But if the drive is still in warranty, you may be able to get it RMAed. That way, it's not just being tossed.

Also, when removing the drive, it adds a tag to the PoolPart folder that says "this folder/drive is removed". (the dpcmd tool also can do this, but does so without moving the data off). And yeah, what shane said about the folder .... it sounds like the folder entry may have gotten corrupted. This can cause issues, up to and including the "cannot be added twice" type thing. That said, if the data recovery software is able to get the files, those should be usable, in theory. StableBit DrivePool stores the whole file on each disk, so provided that the recovered data isn't corrupted, they should be usable.

Yeah, the major OS version updates seem to cause trouble for the driver. Uinstalling and reinstalling the software should fix the issue, though.

Can confirm that those should be the correct files. There should be two groups, and the "Item" has the location bay and case information. This should match what is in StableBit Scanner. But not every entry will have this information. "Item": { "$type": "ScannerServiceLib.Settings.Disk, Scanner.ServiceLib", "Version": 9, "DeviceBlockVersion": 2, "TemperatureOverrideValue": null, "ChangeId": "----", "SmartWarningIgnores": null, "NameAlias": null, "NoSmart": false, "NoDirectIo": false, "NeverAutoScanSurface": false, "RecheckInterval": null, "NeverAutoScanFileSystem": false, "TemperatureOverrideC": null, "QueryPowerModeWithDirectIo": false, "LocationCase": "Column 2", "LocationBay": "Bay 1"

It depends on how the API handles it, TBH. As long as the data is accessible, that's the important part. However, I do believe that the account has to be writable, as some data is written to the provider when the drive is mounted (at the very least, for the "attach"/lock file for the drive. But as shane mentioned, there was a fix related to this in the beta version. However, we've added Google drive to the converter tool, so that you can download the contents, and convert to the local disk provider. This is also in the beta version. Specifically, you'd need to run "CloudDrive.Convert GoogleDriveToLocalDisk" to kick this off.

If you click the arrow for the pool organization bar at the bottom, it should have a "re-balance" option. Does running that help? If it doesn't, then please open a ticket at https://stablebit.com/Contact

Unreadable sectors indicate a catastrophic failure. You definitely shouldn't just ignore them. That said, you can mark them as good until the next scan, here: https://stablebit.com/Support/Scanner/2.X/Manual?Section=Disk Scanning Panel#Sector Map

There are a number of options that will cause the scans to stop. Activity on the disks will throttle or stop the scans. The time may. Etc. You can see these settings here: https://stablebit.com/Support/Scanner/2.X/Manual?Section=General That said, the percentage is a bit ... misleading. StableBit Scanner uses a sector map for the scan, so eaach region is tracked independently. That percentage is based on what is left to be scanned, and *not* the entire disk's progress. You can see that represented here: https://stablebit.com/Support/Scanner/2.X/Manual?Section=Disk Scanning Panel#Sector Map

The limit is actually based on the allocation unit size (aka cluster size). the normal 4kb cluster has that limit. So each volume will still have this limit, regardless if it is in a pool or not. However, the pool itself is an emulated drive, and has no clusters/blocks. So technically, it's limited by what Windows will report, at that point. Changing the allocation unit size requires a refomatting, so you can't do it "on the fly". Another fun caveat is that NTFS doesn't support VSS snapshots on volumes over 64TBs. Which means no CHKDSK pass on volumes larger than that, as well. And shane's comments are spot on. As usual.

"C:\ProgramData\StableBit DrivePool\Service\Store\Json" is where the settings are located. And it should have full control for the "SYSTEM" account, as that's what the service runs in.

If you did a manual reset, that will clear the settings. Otherwise, could you open a ticket at https://stablebit.com/contact? This is definitely something tha shouldn't be happening (and can verify that it keeps the settings just fine on my system)

Well, StableBit DrivePool does support adding a Storage Spaces array to the pool. So until you have more disks and are able to migrate the data away, you could add both to a pool.

Specifically, StableBit DrivePool and Windows doesn't need letters for the disks, nor even folder mount paths. These are there to make it easier for users to access the drives. But as somebody with 20+ drives, mounting the drives to folders makes things very easy. And we do have a guide on how to do so: https://wiki.covecube.com/StableBit_DrivePool_Q4822624

Just a heads up, the duplication is essentially copying files from one of the drives to another drive. The speed depends on a number of factors, such as the size of the files being moved (more and smaller files will take longer than less and larger files, for the same amount of data). Also, factors such as pool usage will impact this, since the duplication pass runs in a bachground priority. You can temporarily boost the priority by clicking in the >> button next to the bar. There is also an advanced setting to permanently boost the priority too. https://wiki.covecube.com/StableBit_DrivePool_2.x_Advanced_Settings The "FileDuplication_BackgroundIO" setting controls this.

The only providers supported are the ones listed by the convert tool. Which is currently: Dropbox to local local to file share file share to local

Also, for the larger drives, a larger cluster (or allocation unit size), can help, especially if you're mostly storing larger files on them. More sequential data.

also, if it's not a powered USB hub... even with externally powered usb drives... an unpowered usb hub can behave erratically. And "resmon" can be useful. The disks tab can show you what is open, where, the disk queue length, etc.

It should show up in the pool UI's pie chart, not on the disks themselves.

Yeah, can confirm. Last time I looked, it supported using SSDs or memory for caching. It's definitely a good option here.

That's a network drive, not an internal drive. It's mapped to a network share on "\\VBoxSvr\Toshiba_HDD_1TB". So StableBit DrivePool won't be able to use it. You need to actually pass through the disk, (not just share it), or you can use StableBit CloudDrive and the Windows File Share provider to create a disk on the shared disk.