Shane

Yes, the Cloud app does seem to be incorrectly adding them together as separate pools even though it seems to have detected there's a hierarchical arrangement.

I believe it's used when DrivePool has a choice of drive(s) to pick; a seek penalty will influence which are chosen. E.g. if you tell it to open a file (e.g. a movie) that's stored on more than one drive in the pool, it will look at which of those drives are busy and which have no penalty. So if your file was on a SSD and a HDD it would prefer to open it from the SSD unless the latter was already busy with something else. The update means this now also applies to nested pools; in such situations (e.g. a pool consisting of a pool of SSDs and a pool of HDDs) the combined pool can now know which of it's comprising pools have no seek penalty.

If the SSD was tested on the same port on the PC as the Syba then that would rule out the PC (at least in theory; in practice it could still be a combination of the interaction between the particular chipsets), leaving only the Syba as the common factor. Otherwise while I too would suspect the Syba here, we couldn't entirely rule out the PC.

If you have drives X and Y comprising pool Z, then directly accessing X:\PoolPart or Y:\PoolPart yourself rather than through Z:\ means you're not using DrivePool - so if you're still getting the same capped total speed then the problem isn't DrivePool. You might need to look at the USB 3.x controller you're using, perhaps there is an issue there / a driver update available? What is the brand/model of the DAS?

I know that Windows will always check the available space against the total size of the folders/files to be copied, or when moving those between different drives, but I'm surprised that's happening when moving files within the same pool as I'm under the impression that should appear to Windows to be the same "drive".

Q. "I use File Juggler for this, as I saw no way at all to do this via balancing rules (file date, file size is not present). Unless I'm mistaken?" A. Correct, DrivePool's balancing doesn't support balancing by file date or file size, only by file name. Q. "I have mounted the SSD and the HDD pool to empty NTFS folders, and file juggler interacts with those. Will this mess up my pools at all? I would assume not?" A. If the File Juggler program is pointed at a pool, there shouldn't be any issue. If the File Juggler program is pointed at a poolpart (one of the hidden folders that comprise a pool) then it could mess up DrivePool's measuring which could in turn affect balancing; if you find this is happening and File Juggler can run a command or script after it completes a juggle then you may wish to have it order DrivePool to perform a re-measure (DrivePool may also automatically initiate a re-measure if it notices the discrepancy). Q. "Regarding my HDD pool, I would like it if the balancing is only done with newly written files. So no files get moved from one disk to another. Is this possible?" A. Given what you've described, for the "HDD Pool" I would remove Disk Space Equalizer and would suggest using Prevent Drive Overfill instead.

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).