Leaderboard

It's flaky because multicast detection can be flaky. That said, you can manually add entries, if you need to: https://wiki.covecube.com/StableBit_DrivePool_2.x_Advanced_Settings#RemoteControl.xml

I'm not positive what version the original server was running at the time and i have no way to check. That sadly as it's not even the same OS drive so i can't just use event viewer to try and go back. How ever i did state that chatgpt didn't get any of the version numbers correct for any of stable bit as it thinks stablebit is somehow on like 2.4.XX.XXXX and as far as i can tell there is no such version ever. as i said AI is cool and can give helpful advice but for the most part AI is kind of trash in it's current state for most anything. It's crazy to think that multi billion$ company's are relying on this thing to manage ppl or even other AI. either way im happy its working if i could give you a reason it's working outside of it just is i would. I just know i tried the lower ver multiple times and had no luck over the last 2-3months and my pool is about 284TB so every time i ran one of them commands to force any type of access it took many hours.

SyncThing does not rely at all on persistent FileID and does not rely solely on watcher notifications, thus it is not vulnerable to DrivePool's FileID collisions and is insulated against DrivePool's change notification bug. However, as MitchC mentioned, there is another DrivePool issue, the Read Striping bug. While that bug is apparently not omnipresent across installs (so you may just be one of the lucky ones) and requires Read Striping to be both enabled (warning this is currently the default on new installs) and active (because even if enabled it only affects pools that are using duplication) it is definitely something to be neutralised. TLDR as far as solely SyncThing + DrivePool is concerned, if you're not using duplication you're fine and if you are using duplication but not using Read Striping you're fine; if you have been using duplication and Read Striping then you should disable the latter and check for corrupted files (and the nature of the bug means a file corrupted on one pool could then be synced to the other pool in that corrupted state).

If this is bi-directional syncing as well this is a bit of the nightmare scenario for this bug. 80TB is a massive amount if you had just 00.1% of your data (aka 100GB) changed would you notice? SHA hashing of every file is good at detecting ordinary corruption but would likely not catch the data loss this set of bugs can cause. The issue here would appear more like you overwrote a file with new content intentionally (or depending on the application that you copied a file over another). I can assume if your data is all pristine then Syncthing probably doesn't use file ID's right now. It is well shown that drivepools file change notification system has multiple large flaws. Many applications can trigger a 'file content changed' notification from Windows even when they are only reading it. Maybe syncthing checks the file timestamp and size at that point and if its the same it does nothing. If it listens to the file system though at best you just have the file completely read and re-hashed for sync-thing to decide no changes, at worst it just queues it for syncing and you sync extra data. Either way you could be wearing the drives out faster that needed, losing performance, or potentially wasting bandwidth and backup time. We also know that drivepool does not properly bubble up file change notifications when writes actually happen which, depending how syncthing is watching, could mean it misses some files that change. Not a huge deal but if it does a full scan monthly to make sure it has all file changes detected and in between you rely on file change notifications to catch files to sync it means you might think everything was in sync to right before a crash when in reality it might be up to a month out of date. If the file is likely to actually have changed (say a log file) I would say unrelated. Even for one time writes, it could be the application was still writing the file as well when syncthing starts hashing and again not related. It is also possible though that it goes to read a changed file, but causes the notification bug so it gets the file has changed and then provides that warning. This could be a race condition as it would likely cause it right at the start of the read so depending when it starts considering the notifications after it reads to be a change it may only happen some times. Another option would be if something else also has file change notifications then if the other app reads the file after syncthing starts reading it the other app causes a 'write notification' even though its only reading due ot this bug. First, there is 0% chance these bugs are not critically problematic with drivepool. They can lead to direct data loss or corruption and sensitive data to be leaked which is a horrid statement for a file system. The question is do these bugs affect your specific use case. The problem is it may not present uniformly. Maybe syncthing does diff based syncing for only the parts of a file that changed for bigger files (say over 10MB) but any files it thinks have changed that are under 10MB it just syncs them blindly as they are so small and it keeps cpu usage down. Maybe it uses a more simple solution. If a file is 'changed' it tries to optimize append based changes. It hashes the file file size and if that equals the old hash it knows it only needs to sync the newer bytes, otherwise it syncs the whole file. Even if the worst that happens right now is you have excess drive reads of bandwidth spend that speaks nothing of tomorrow. Maybe syncthing decides it does not need to hash a file when it gets a change notification as that causes a full additional read of the entire file (hurting performance and drive life) so it starts to just trust windows file change notifications. Maybe you never even upgrade syncthing but right now you don't use an application that triggers the 'file content changed' notification when it just opens a file for reading (IE VSCode might not but something like notepad does). You start using a new file editor or video player and now it does trigger that bug, so now syncthing is getting a whole lot more of these change notifications. When you upgrade syncthing do you read about all changes between versions? Who knows if some internal changes wold even make the change log. If syncthing starts relying on FileID's more in the next version then your data may slowly corrupt. If most of your data doesn't change then hashing it all now, and hashing it down the line and comparing would show you if a file changes that shouldn't. This is not the same hashing that syncthing does as it is looking for corruption from the system/disk/transfer and not for the file contents being updated on purpose. Still, even then as these bugs are likely to effect files that change more often first that may not catch things quickly (mainly there you are waiting for it to go to write a FileID of one of the new files but it ends up overriding an old file instead). I briefly looked at syncthings documentation that it said it compares file modification times for detecting if a file changed. I don't know if their documentation just didn't mention it using size as well or if it actually only looks at the modification time to detect changes. If so this could be more risky as well. Personally I moved to Truenas which while not as flexible in terms of drive pooling got me what I wanted and the snapshotting makes backups fantastic. For others if unraid or similar is possible you could still have such flexibility without the liability of drivepool. This is not a fun game of chance to play where you are hoping you don't find yourself using the wrong combination of apps that leads to data loss. Drivepool clearly works (at least mostly as many may not know perf or other issues are caused by drivepool) correct for most people. Because of the exceptional difficulty of knowing how these bugs could effect you today or in the future I still see it as quite reckless that drivepool does not at least warn you of these possibilities. This is not dis-similar to the fact that there seems to be a decent bug in reading striped data from drivepool for multiple users yet there is no such warning that striping can cause such a bad issue:

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

Hi Shane I ran HDD regenerator & seatools on a different PC, which doesn't have SB scanner installed. Although HDD regenerator reported issues with 7 sectors & recommended backing up the HDD, it didn't actually report any bad sectors in the section below the progress graph but obviously it found something it didn't like, hence the suggestion. I've 6 HDD's & 1 SSD on the PC that reported the problem; one of the HDD I only replaced after the issue with the problem drive & everything is normal even using the same SATA port & data cable, so it seems the HDD that has the problem is actually faulty but seatools says it's OK! I've RMA'd the HDD & returned it to Seagate so can no longer test it.

A few options that come to mind: You can right-click the column labels row in the Scanner GUI and enable display of drive letters if it isn't showing those. You can right-click a specific disk and select "Disk Settings" to (amongst other options) change the Name of it from the default (the latter usually being its model code) to something you can more easily match with DrivePool. If you don't use drive letters for your poolpart drives, you can mount them to a path in Windows Disk Manager (e.g. c:\disks\1, c:\disks\2, c:\disks\3, etc) and both Scanner and DrivePool will show that path instead of the drive letter.