Christopher (Drashna)

a couple of things to add to that, I do recommend running "netsh int tcp set global autotuninglevel=highlyrestricted" from an elevated command prompt on any Windows system. The normal "autotuning" setting is overly aggressive and causes a lot of issues, in my experience (sadly, this has been an issue since even the Vista days). Also, on your network adapter, disabling options like "green ethernet", any settings with "checksum" or "offload" in the name, "interrupt modulation", may help with performance and reliability. I'd like to say "reportedly bugged".

No, it dosen't have any preference. But if you have read striping enabled, it should use that to optimize the reads. However, you might be able to use the file placement rules to hack this. Eg, add a rule for "\.covefs\*" should work (or at least, dosen't error out). This should allow you to specify a drive (and testing this, it looks to be respected)

You can also do this with power shell, and with "two" commands. In both cases, this gets a list of disks -> checks for any items that have the "read only property" -> and for each, run the command to disable read only. These are safe to run, and I have verified that they cause no issue on my personal system/server.

To jump in late here, yeah, this sounds very much like a disk issue. A bad cable, connection or even drive may be the culprit here. I would recommend reseating the cables for the drives having issues, or even replacing them (I've actually had SATA cables "burn out", in the past ...). And if that doesn't help, disconnect the drive. If keeping it disconnected clears up the issues, there may be an issue with drive itself (such as the pcb controller on it), and you may want/need to RMA this drive (sooner rather than later).

Ah, okay. So just another term like "spinning rust" And that's ... very neat! You are very welcome! And I'm in that same boat, TBH. Zfs and btrfs look like good pooling solutions, but a lot that goes into them. Unraid is another option, but honestly, one I'm not fond of, mainly because of how the licensing works (I ... may be spoiled by our own licensing, I admit). And yeah, the recovery and such for the software is great. A lot of time and effort has gone into making it so easy, and we're glad you appreciate that! And the file recovery does make things nice, when you're in a pinch! And I definitely understand why people keep asking for a linux and/or mac version of our software. There is a lot to say about something that "just works".

What if the file is duplicated, and exists on multiple drives? What if the file needs to be moved to another drive, but not all copies of it need to be? Etc. It's not that it's not possible, but the additional overhead of all of these edge cases (and more that I can't think of aff the top of my head) make things a LOT more complex. And since some of this branched checking needs to happen in the kernel ... the longer it takes, the more it will adversely impact the system. It's a similar reason for why we don't support dynamic disks, either.

Usually the stack text has 10-12 lines, so it not is ... very odd. And if it does happen again, I do recommend running the StableBit Troubleshooter after opening a ticket (so you can get the ticket ID, or just use 30727). The troubleshooter will compress the crash dumps, and upload them, along with other logs that tend to be useful. Hopefully, you won't need to do that, but in case you do.

Could you open a ticket at https://stablebit.com/Contact ? And this is odd. Everything looks to check out, and checksum is valid, so it should work. But checking the ignore checksum and signauter options may help

That's ... very odd. If the issues comes back, let us know (and open a ticket at https://stablebit.com/Contact)

I'm with shane, on the duplicating important files. Very important stuff with x3. But bulk media? Unless it's personal stuff, I don't bother. The amount of data I have makes it not worth bothering. As for the performance hit, that's not too surprising. There is a lot that goes into that, and even on a bare drive, you can see drops like that. Also, you said "e-waste drives". If these are previously used, the chances of issues are much higher, and may impact performance, too. And if it makes you feel any better, I've switched most of my systems over to linux, but the server stays on Windows plus StableBit DrivePool. There are other solutions out there, for sure, but StableBit DrivePool is just drop dead simple.

A new thread would have been better, here, IMO. I do believe that you've opened a ticket already. But just in case, enabling drive tracing and posting the logs to a ticket would be a good idea: https://wiki.covecube.com/StableBit_DrivePool_2.x_Log_Collection

Make sure you have the latest version installed: https://dl.covecube.com/DrivePoolWindows/release/download/StableBit.DrivePool_2.3.12.1683_x64_Release.exe (There are some memory hardening things in there that may help) Also, if you're still seeing BSOD's they should be reported to https://stablebit.com/Contact (Also, you cut off the log right before it shows the memory operations, and are the most important part of the printout). And the covefs.sys driver is our driver, and the pool driver, specifically.

For StableBit DrivePool, the only setting that can impact this is the "BitLocker" detection setting. https://wiki.covecube.com/StableBit_DrivePool_2.x_Advanced_Settings The setting in question is the example for how to edit and disable the setting, actually (and coincidentally). Also, make sure that you do not use A:\ or B:\ for the pool's drive letter, as Windows has some hard coded behavior that pings these drive letters frequently under the assumption that they're floppy drives. If you have StableBit Scanner installed, then in the Scanner Settings, enable the "throttle queries" option in the SMART tab, as this can cause the drives to wake up or stay active.

Also: https://stablebit.com/Support/DrivePool/Licensing So technically, not quite a read only state. And for the trial period ending, if the system date and time was not correct and updated, it could trigger this sort of behavior.

What shane said. Also, depending on the backplane, adding a fan (or changing the fan curve for that fan, or replacing it with a more powerful fan) may be a good idea.

For any and all licensing requests, you should always head to https://stablebit.com/Contact first. And for these, we should get to licensing tickets within the day or so. And for support tickets, within a business day or so. I say "or so", given time zones, scheduling, etc. It may not be exactly a day. If it takes longer than that, please feel free to bump the ticket, or email me directly at christopher@covecube.com. (sorry, this may/does get a bit ranty) Some of those threads, we've looked into the issues, and can't reproduce. So without being able to do so, it is very hard to a) verify that the issue exists, b) verify that the issue is actually related to our software, and c) address the issues. And there is only so many ways to say that before it sounds canned and/or condescending. That said, if we could "wave our hands and make the issues go away", we'd absolutely do so (and not in a "delete the thread and pretend it never happened" sort of way). Also, in general, I have personally found forums and other public places a bad place to to do support. Too much dogpiling of issues that may not actually be related. And this isn't something that is strictly related to StableBit DrivePool. I've seen it in open source projects I've worked on too, for instance. It makes things messier and harder to actually deal with real issues. One on one is always ideal for support. If there are paterns that emerge, that can be reported on internally, and much more naturally/organically. Eg, "Hey, I have these few tickets that are exhibiting the same or very similar behavior, so there definitely looks to be an issue here" sort of thing (which has happened a number of times).

Glad to hear it! Well, not the drive part, but that StableBit DrivePool just did it's thing.

If you're running into issues with this, then no, it hasn't been fixed. Specifically, this isn't something that is fixable on our end (without possibly breaking things), and is something that Google/Alphabet would need to fix in their software.

I'm sorry, what are you talking about? Aside from balancing and duplication, StableBit DrivePool doesn't concern itself about files and Windows. https://stablebit.com/Support/DrivePool/2.X/Manual?Section=About Balancing https://stablebit.com/Support/DrivePool/2.X/Manual?Section=File Protection https://stablebit.com/Support/DrivePool/2.X/Manual?Section=Pool Organization Bar Would you mind posting a screenshot of what you mean? Either here, or at https://stablebit.com/Contact

There isn't really a one size fits all answer here. But it really boils down to what you're storing and how much do you want to micromanage. Personally, I just use a single, large pool. And it is quite large. As for the measuring, this can take a while, especially if you have a lot of small files to measure. Checking each file is resource intensive because of how file operations work. But this shouldn't happen very often. As for balancing/duplication, this can also take a while to complete. Both are a multi step process that checks what needs to be moved, where it should be moved, and then moves/copies it. The file copy uses the normal win32 api for moving files, but uses a background priority, so it can take longer if your pool is actively in use.

In some cases, resetting/Rebuilding WMI can fix weird issues. "Winmgmt /resetrepository" from an elevated command prompt and rebooting the system can help.

To be blunt, this doesn't sound like it's an issue with duplication, at all, but rather is an issue with NTFS permissions. Worst case, you can reset the permissions on the whole pool by reapplying them: https://wiki.covecube.com/StableBit_DrivePool_Q5510455

2.3.11.1663 should be safe for people with existing pools. However, if you're an older version ow Windows, then you may need to use 2.3.8.1600 due to signing issues. As for folder enumeration issues, there isn't a specific fix for this, and ChatGPT is *not* a reliable source of information, ever. LLMs are incredibly prone to "halluciating" (a nice way to say "making shit up with no basis in reality"). And the absolute latest release is: https://dl.covecube.com/DrivePoolWindows/release/download/StableBit.DrivePool_2.3.12.1680_x64_Release.exe If you're having issues on the newer versions, please open a ticket at https://stablebit.com/Contact

Depends on what you mean by local notifications. Email, SMS, and mobile notifications should be available. As well as Speech powered by TTS in Windows. As for system to system notification, no, that is not supported.

StableBit DrivePool expects all of the pooled disks to be kept togethor. You can't just grab one drive from the pool (well you can, but the system will complain about the now missing disk). That said, you can "seed" the pool, eg move the files into the pool structure without having to copy the files over and without losing the folder structure: https://wiki.covecube.com/StableBit_DrivePool_Q4142489 And the poolpart folders you mention are hidden by default. We don't recommend accessing or manipulating files from these folders normally, as it can cause issues long term. But for initial conversion/adoption, the seeding process is fine (since it's a one time thing, and is done).