Shane

I can't comment officially as I'm just a volunteer mod (see my sig below). Having another look, the Notifications menu entry in DrivePool being missing when it's not linked to the Cloud service seems like a bug? New versions of DrivePool, Scanner and Cloud were just released yesterday so check if those make a difference, and if they don't then I'd suggest opening a support request with StableBit directly.

Were you able to figure this out? I also use Firefox and save to a network share (well, a mapped drive of a network share) that is a DrivePool pool on the other end but haven't encountered this error, fwiw.

Drive might still be usable - sometimes you get lucky and the bad sectors don't breed, and if so chkdsk /r will at least mark those sectors to not be used by the file system - but if you don't want the risk that you'll end up with more and more bad sectors then yeah wipe and bin/rma the drive.

Perhaps a combination of CyLog's FillDisk (does what it implies: fills a disk with files full of zeroes) and StableBit's Scanner (scans drive sectors to verify they're readable)? There's also utilities such as Seagate Tools and HDDScan.

VapechiK is correct; StableBit's DrivePool is not a parity RAID system, it will not "self-heal" a damaged file. StableBit's Scanner is able to detect and attempt to repair damaged files, and if you have that plus DrivePool's duplication you can manually replace a non-repairable file with its good duplicate when alerted. Some users combine DrivePool with SnapRAID to get parity healing capability (albeit not fully automated). As VapechiK indicates, you can also pool sets of RAID volumes to let those provide duplication/parity.

DrivePool does not automatically remove empty folders from poolparts during balancing (basically for redundancy reasons; some pool metadata is stored as AD streams attached to the folders and the "space cost" of this is normally very low). The upshot is that so long as the "abracadabra" folder tree is showing 0 bytes (as an administrator) and does not contain any hidden system folders (e.g. $recycle.bin or system volume information) then it can be safely removed manually while the DrivePool service is stopped; the only thing you'd "lose" is some extra redundancy.

If you reduce or turn off Duplication (for a folder or the pool) then DrivePool simply goes through and deletes the excess instances. If you have some files that you wish to keep duplicated then you can manage duplication on a per-folder (or folder tree) basis, e.g. I have a bunch of files I don't care about at in folders at x1, some I care about at in folders at x2 and some that I absolutely want safe that I keep in folders at x3 (and I have a backup of everything anyway externally). There's also SnapRAID which takes a different approach (it uses parity drives) but can be used in conjunction with DrivePool. Pros and cons.

A seek penalty (in the context of storage devices) refers to a storage device needing additional time to perform a seek (begin retrieving data), and the OS can request a storage device to report whether or not it has a seek penalty (or how big it is). Mechanical hard drives have a seek penalty - they need time for the platter(s) to spin and for the head(s) to move into position before they can begin accessing data. Solid state drives (and RAM drives) usually do not (or it's very small). You can get edge cases where a drive might not itself have a seek penalty but the path to it does (e.g. a SSD being virtually mounted over a slow network). TLDR it can be a reasonably accurate indicator as to whether a device is a HDD or SSD (or at least close enough for practical purposes).

If it's none of the above, I could only speculate blindly. Perhaps some file filter driver from another app? Some weird issue in the JBOD firmware? You could also try resetting DrivePool's settings and application state if something in there has come unglued. If you end up still stuck, I'd suggest contacting StableBit.

It asks you whether you want #1 it to use the most recent versions of the file(s) or #2 to manually fix it yourself.

That's normal; DrivePool may itself detect when it needs to do a re-measure.

After a reboot, does manually creating a new folder or copying new data into each of the hidden poolpart folders cause the error on any drive(s), or is it only when creating/copying in the virtual pool drive? Do you have particularly-paranoid antivirus software, and does (temporarily) disabling and/or uninstalling it make the problem disappear? P.S. I've found that Q5510455 can fix most NTFS permission errors but unfortunately there are still a few it won't. See here for an alternative, more thorough method.

That's correct.

If the content I want to put into the pool is already on one of the drives (about to be) in the pool, I prefer to (add the drive and) manually move the content into the poolpart. As you noted, it's almost instant. One thing I do to reduce any risk of accidentally conflicting files or folders across poolparts is to create a unique folder to move the content into; e.g. if I have a pool "P:\" then - after I've stopped the service - I create a unique folder in the poolpart (e.g. "D:\poolpart.xyz\123" where there wasn't previously a "P:\123") and move what I want into that unique folder - then I can start the service back up and remeasure, and any further moving can be done via the pool rather than the poolpart; I don't even have to wait for the remeasure to finish).

I believe the short answer is that single-file-at-a-time balancing was by far the simplest and safest to code*, so guaranteed reliability (and more time to code other things) was chosen over raw speed. *In my very limited and outdated experience, multi-threaded operations are fantastic when you can just tick a checkbox in a compiler that can safely (hah) optimise it all for you, and a complex pile of risk conditions when you have to write it yourself.

Moving the files into the poolpart while the service is stopped prevents any risk of DrivePool attempting to move the files while you're moving the files. Personally I haven't found it necessary to reset DrivePool's settings afterwards, as per the KB article, instead just using Manage Pool -> Re-measure afterwards (and if I'm using duplication, making sure that is appropriately set for the new folders and then Troubleshooting -> Recheck Duplication afterwards), but your mileage may vary.

Hi toyoda, as I understand it a license transfer can be triggered by a significant change in hardware or OS. If that's not happening then you'd need to contact StableBit directly for support so they can figure out what is setting it off.

Each drive (technically each volume) has only one poolpart, so you only need to worry about what comes after the poolpart.longhexname section in the path (the exampleX vs exampleY). If Windows is seeing the drive as write-protected then it might not be possible to move the files off it (copy yes, move no). You might try using diskpart as an administrator to list volume and then select volume # to select the volume, then use the attributes disk command to see whether the readonly flag has been set on the disk, and attempt to clear it if so (attributes disk clear readonly) before using exit to exit diskpart. Another possibility is that the file system on the drive has been corrupted in a way that Windows can't fix without formatting the drive.

If you've got one of the tools I suggested above, you can just type the file name (or a part of it) into it and it'll show a list of matching files across all of your drives. I've got my poolpart drives mounted as e:\disks\number where number is each drive's serial number, so hypothetically I might type in "invoice 67" and Everything might show me that "invoice 67.pdf" is in "e:\disks\wcc-xyz\poolpart.bleh\docs\2021\" and "e:\disks\st-abc\poolpart.bleh\docs\2021\". FWIW, here's how I went about mounting all of my poolpart drives: use Windows Disk Management to shrink my c:\ partition by 8GB and add a simple NTFS-formatted volume e:\ using that free space use Windows File Explorer to create a folder e:\disks and then a bunch of empty subfolders 01, 02, 03, et cetera within that folder use Windows Disk Management to remove any/all drive letters from my poolpart drives and instead mount each poolpart drive to those ## subfolders until every drive has its own e:\disks\## attached to it the disks will show up in both DrivePool (under the "Disks" column) and Scanner (under the "Drive Letter" column) with those ## paths and their serial numbers will show up too (in DrivePool by hovering the mouse cursor over each disk and in Scanner under the "Serial Number" column). use Windows File Explorer to rename each ## folder to their respective serial numbers - DrivePool and Scanner will automatically update accordingly if I add a new disk, see steps 2 through 5. I do it this way so that I can easily restrict Everything to only the contents of my poolpart drives by typing in e:\ as the first search term (e.g. "e:\ .pdf" will show me the drive and folder location of every PDF document in my pool).

You can use Windows Disk Management to mount the drives as folders, e.g. d:\disks\drive1, d:\disks\drive2, etc, so that you can still individually access each drive without having to give them letters. Note: do NOT mount a drive, that's part of a pool, as a folder within a pool.

Windows ceasing to recognise a HDD during balancing suggests you have flaky hardware/drivers. You might be able to narrow the cause down by observing which drive(s) drop out and rearranging them to see if that changes (e.g. if it's always the same drive regardless of port then it's probably the drive, if it's always the same cable or port regardless of drive then it's probably the cable or port or the port's controller/driver, etc). If that doesn't seem to be it, then it might be a power delivery issue (e.g. if you have a lot of drives and/or USB-powered ones). If balancing is interrupted (in the GUI, the organization bar should be incomplete with an upward-pointing triangle on the right) then you can resume balancing by clicking the triangle and then clicking Re-balance. You can also "force" a balancing check by using Manage Pool -> Balancing, clicking "Balance immediately" (even if it's already set) and then just click Save - but note that DrivePool still won't start balancing unless it finds something to balance. You can manually "balance" files between the hidden poolpart folders that DrivePool creates on the drives that form a pool. You should ensure you maintain the folder structure within the poolparts (e.g. it is fine to manually move a file from d:\poolpart.1\exampleX\ to e:\poolpart.2\exampleX\ but manually moving a file from d:\poolpart.1\exampleX\ to e:\poolpart.2\exampleY\ should only be done if you understand what you're doing). You should manually stop the DrivePool service before doing so, start the service afterwards and then use Manage Pool -> Re-measure so that DrivePool can rebuild its pool and drive metrics. Note that DrivePool will still perform its own balancing (if set) afterwards. But personally I'd want to sort out whatever's causing the drives to drop out before trying this.

Personally I use Everything by Voidtools; I also know of UltraSearch by JAM and SwiftSearch by wfunction. So long as your drives either have letters or mount paths they can quickly find files across multiple drives.

Correct, at least based on my own past experiences.

DrivePool's duplication in real-time mode shouldn't have a problem; the performance hit is quite small. Schedule-based duplication may or may not be problematic depending on camera outputs vs drive/connection performance (e.g. will there be issues with recording streams to a drive if previous recordings on the drive are also being read). Also schedule-based duplication will not duplicate any files that are being held open for writing at the time). Other concerns that come to mind: Free space of drives versus free space of pool. The pool reports the combined free space to Windows/apps, but any given file is limited to the free space of the drive being written to - e.g. if your app needs to record 2TB of video to the pool as a single file and the drives in the pool have 3TB combined free but only 1TB free on any given drive then the app will unexpectedly run out of space; some apps don't handle this well. However if you can know the largest recording will be X size (e.g. maybe the app has a splitting option) then you can set the pool to fill each drive to less than capacity-X to avoid this problem. In the event of a drive in a pool failing completely/suddenly, DrivePool switches that pool to read-only to prevent potential file conflicts; this is not optimal if you're wanting the (other) cameras using that pool to continue recording. You may wish to consider multiple pools (e.g. one per X cameras)* and/or a pool consisting of (via software or hardware) multiple RAID1 mirrored pairs, RAID5 striped sets or similar, so that in the event of drive failure(s) an affected pool can remain writable while using Scanner or similar to notify you of the failure. *This may also be desirable depending on the bandwidth required by the cameras plus any expected maintenance / user operations versus the speed of the drives.

Licenses linked to stablebit cloud can be reassigned via the cloud portal without needing to deactivate a stablebit app manually (e.g. before a windows reinstall). Otherwise you need to manually deactivate the app first or - e.g. if windows falls over and can't get up - you may need to contact stablebit support to have them release the license.