Christopher (Drashna)
-
Posts
11568 -
Joined
-
Last visited
-
Days Won
366
Posts posted by Christopher (Drashna)
-
-
"0x80070643" indicates that the system has a pending reboot. Rebooting the system will usually fix this issue.
If not, this will:
-
This is for older versions of StableBit DrivePool and StableBit Scanner. Updating to the latest version will fix this.
-
I don't believe it does. But I'm not certain.
However, let me flag this for Alex: https://stablebit.com/Admin/IssueAnalysis/28716
-
No. There are no plans on implementing this sort of functionality.
-
Yes and no.
Specifically, by default, StableBit Scanner will only scan one drive per controller. And in fact, you have to get into the advanced configuration to increase that.
So if you're seeing multiple drives being scanned at once, it's likely because they are connected to different controllers (you can verify this by selecting the "group by controllers" option in the UI.
-
-
Yeah, it's a known issue. It has to do with how the "on demand" feature works, and that it's not supported on the emulated drive that StableBit CloudDrive.
Also, it's not just a sparse file, it's a special type of file, that requires file system support. And because we use an emulated drive, we'd have to reverse engineer that and add support for it.
A possible solution is to create a StableBit CloudDrive disk on the pool and use that. But I can understand not wanting to do that.
-
Yes. New data will be stored in the local cache, until it's able to be uploaded.
If this is in regards to the 750GB per day, per account upload limit, throttling the upload speed to ~80mbps should help prevent hitting that limit.
-
Well thanks! And yeah, it's a perpetual problem. Antivirus vendors don't like new releases from small software vendors.
-
Could you open a ticket at https://stablebit.com/contact about this?
-
A quick look into this shows that there may not really be any performance difference, especially as data may not be staying on the drive (depending on how you use them)
-
Do you have a "found.###" folder in the root of your drive? If so, the data may be there.
Also something like WinDirStat or WizTree can be good for visualizing where the data is.
-
-
-
Unfortunately, this come up from time to time, especially on new versions.
We usually try to report to false positive when we're notificed about it.
-
For the surface scan, StableBit Scanner doesn't do anything to fix/correct the unreadable sectors. You can clear the status, but the next scan, they will likely come back.
That said, the only way to permanently clear the status is to write to the effected sectors. StableBit Scanner doesn't do this, as it prevents the ability to recover the data from the disk.
However, the simplest (but definitely not "best") way to clear the status is to do a full format pass of the drive. This writes zeros to the entire drive, and may correct the issue. If this doesn't work, then you may want to consider replacing the drive (RMA it if it's under warranty)
-
You have to detach the drive, and reattach it, to move the cache.
-
You can get larger than that, but I wouldn't recommend anything about 64TBs, as NTFS cannot run CHKDSK passes on volumes larger than that.
-
I think you're looking for this:
https://stablebit.com/Support/Scanner/2.X/Manual?Section=Disk Scanning Panel#Sector MapAs for getting rid of the warnings: Don't. If these are unreadable sectors, they are exactly what they sound like: spots on the disk that StableBit Scanner was not able to read from, at all. (or at least, in a reasonably timely manner). This can sometimes happen if there are communication issues (such as a loose or bad cable), but if they consistently return, it indicates an issue.
The best way to clear the status is writing to those sectors. StableBit Scanner isn't designed to do this, as it actively avoids writing to the disks.
However, a full, non-quick format pass may correct these unreadable sectors. -
The NVMe drive completely failed? If so, I'm sorry to hear that!
As for the pool, yeah, once you remove the missing drive, it will remeasure the pool, and then run a duplication pass, reduplicating any of the data that needs it.
-
There isn't a good answer for this, and it varies from person to person.
I would recommend x2, normally, and x3 for anything that is especially important and you cannot lose. (and copy that stuff elsewhere, such as to the cloud).
-
Previous Versions, aka shadowcopies aka System Restor use the "System Volume Information" folder to save a snapshot of the files. This happens only on the actual drives (not the pool drive), and counts as "other" data.
You can disable this in the system properties, if you want, by running "SystemPropertiesProtection". You can disable and delete the "protection" for these drives.
-
Specifically, as long as the software isn't actively balancing or duplicating data, you should be okay with doing so.
On 10/23/2022 at 2:37 PM, phhowe17 said:I was thinking of doing this, but I have an instance of a .copytemp file not matching the original file. Looks like the copytemp file is incomplete
If the computer crashed/BSOD/etc, while the data was running balancing or duplication, then this could happen. In fact, that's exactly why we use the copytemp extension for these processes. So, that if the process is interupted for some reason, that you don't have a partial file left on the pool, effectively creating a corrupted copy.
You should be okay to delete the file.
-
There isn't a way built in, but there is this user created guide:
What is this error message all about - first time ever having an "update" issue?
in General
Posted
It's a one time thing, basically. Newer versions have significantly reworked update code.