lvau

No, it's still counting for him and he's watching, for nearly 2 years by now.

Yes, it is, and interestingly the disks can still spin down because this is coming out of the cache. Nothing to worry about.

There is no parity in Drivepool, only mirroring of files. So your first example is what will happen.

It seems to see an issue with ALL drives, as it wants to empty all of them (the blue marker at the beginning is the target where it wants to see the fill state of the drive). Of course it gets stuck at 0% as it has no place to move the data too, as it wants to empty all drives at once. Seems like a bug to me, you should open a support ticket. Disabling the Stablebit Scanner Balancer plugin should solve the issue temporarily.

3x WD Green drives (1, 1.5 and 2TB) from 2009 still spinning fine here without any issues and over 12 years power on time by now. Second old couple are 2x WD Green 4TB recertified drives from 2017 with over 5 years power on time. All of them get a short smart test each day and a extended smart test all 3 weeks. Not a single issue with any of them yet. Will keep then until they die and of course got everything backed up, so no need to swap anything before they die and also eager to see how much longer they will last.

I respectfully disagree with Christopher's opinion. In fact, NTFS is an outdated file system that was not designed for modern usage, for the following reasons: 1) NTFS is over 30 years old and was never intended for large volumes such as those used today. Consequently, NTFS is considered a "hacky" file system. 2) In contrast, ReFS is a modern COW (copy on write) file system that is much more robust than NTFS. ReFS doesn´t need journaling like NTFS. Furthermore, ReFS is not prone to file fragmentation, which can slow down file access and reduce performance on NTFS-formatted drives over time. ReFS has been available and developed for a decade and by now is a well-established file system. Personally, I have been using it since 2013 on all my single drives without any issue. 3) Microsoft is retiring NTFS in favor of ReFS and will use ReFS for new Windows 11 installations soon. As evidence, see https://pureinfotech.com/windows-11-refs-support/. For instance, with a hack, Windows Server 2022 can already boot from ReFS. I am currently using it for my boot drive as well, and I no longer have a single NTFS-formatted drive in my system. 4) Numerous recovery tools are now available for worst-case scenarios that support ReFS, and more and more recovery software is supporting the file system. Verify this by googling "refs recovery software." 5) FileIntegrity checks are indeed not enabled by default since they can cause a slight performance hit (less than 2% with the latest ReFS version that comes with Windows Server 2022 in my case). However, they are well worth it since NTFS does not provide this functionality at all. It is easy to enable them afterward using PowerShell. For example, run Set-FileIntegrity D: -Enable $True -Enforce $False (replacing the drive letter with the desired one). Alternatively, one can enable FileIntegrity while formatting the drive by running format D: /q /fs:refs /i:enable (where "/i:enable" is the switch that enables FileIntegrity at the outset). With this feature enabled, "chkdsk" is no longer necessary since the ReFS driver fixes everything automatically on the fly. Therefore, there is no need to take a volume offline ever again. 6) The issue of internal drives being wrongly threaded as external drives has nothing to do with the file system and can be easily resolved by editing the registry. See https://ourcodeworld.com/articles/read/1300/how-to-fix-windows-10-issue-that-displays-internal-sata-connected-ssd-hdd-as-removable. Nonetheless, I have been using two external drives with ReFS for five years without any issue, and I do not force them to be recognized as internal by Windows using the registry hack.

I am on a 9 drives 100% ReFS formatted Drivepool (every single drive) and everything is working fine since 6 weeks so far. No issues.

This is just terrible behavior for a drive pooling software and should be the number one bug that needs to be fixed. Did the devs ever get it addressed or is it still an issue?

Seems like support for Cloud Drive is pretty much dead if looking at this and almost all the other topics which haven't been answered in nearly a year. Not buying this thing for this reason, seems like it's end of life software and not supported anymore.

After re-enabling "Realtime Duplication", which I had previously disabled because I have just one SSD for the landing zone, these checks have disappeared completely. According to the documentation it says that if "Realtime Duplication" is disabled, the Duplication will be ensured to be consistent "at night". So it seems it was exactly that and there is no schedule to plan what "at night" is and when exactly it will happen. My suggestion to the developers: give Drivepool an option to let the user schedule when the Duplication consistency check is being performed. Some of us are working at night and so do I, and just force performing this check at a time the developer thinks is good, is not the best way at all. Thanks.

And it just finished in almost 3 hours. I hope this can be avoided with some setting from happening daily over and over again.

Hi, I have recently observed that Drivepool goes into the "Checking" mode about all 24 hours. I noticed that there is no activity on the pool prior to this, and all disks are in standby mode (spin down) too. Additionally, there are no error messages or disk removals/problems reported before this happens. Eventually, Drivepool then wakes up all disks and enters the "Checking" ("Working on the entire pool.") mode, which seems to be aimed at ensuring file duplication consistency as per the notification/feedback bubble in the GUI. However, I have not enabled any folder or file duplication. As my pool has a size of 35TB and holds millions of files, such a check takes approximately 2 hours, which is unacceptable. Furthermore, this behavior leads to excessive wear on the disks and increases power consumption due to the spinning up of all disks each 24 hours, even when the pool is not used for days. I would appreciate it if you could clarify whether this is intended behavior and suggest a way to prevent it from occurring automatically. Additionally, if this process is necessary, I would like to be able to schedule it at a more convenient time. Manually canceling the check puts the pool organization into an uncertain state afterward, which is not an ideal solution either. An upgrade to the latest beta version 2.3.3.1497 didn´t change the situation either. Thank you for your prompt assistance.

.

.

Update: Got them all going to standby now after using a utility called hdparm to set disk standby timer directly to the disks instead of using the setting from windows power management. Very happy!