Shane

I don't actually know the exact algorithm it uses; with three drives and the goal of maximising free space on multiple drives to fit as many duplicated (x2) files as possible I'd expect it should (attempt to) end up with one drive full and the other two with a roughly equal amount of free space. For example if you have drives A____ B____ and filled them with x2 duplicated files 1 2 3 4 then you'd end up with A1234 B1234. If you then added drive C____ the balancer could try to arrange them something like A1234 B12__ C34__ so it'd then have the most room for additional x2 duplicated files. Something I could play around with to test if I had more minutes of free time lately.

Huh. Fair, that'd be weird. Any chance it could have gotten a start on scanning the sectors before it had to pause for whatever it's waiting for and you saw its (lack of) progress? Or is the screenshot from like "thirty seconds after being plugged in for the first time" and it couldn't possibly have made that much progress even if it started scanning straight away?

A4. Green blocks are groups of sectors that Scanner has already checked and found to be readable (they may initially start off blue as Scanner works). Grey blocks are those that Scanner has never checked yet (or which you've manually cleared to be re-read). If it seems to be stuck on "Waiting to Scan" then either you've turned off automatic scanning or Scanner's settings are having it wait for something else to finish with the disk (Scanner has a LOT of settings as to when and why to scan or to not scan, which can be accessed via Settings -> Scanner Settings or you can select a "set" of defaults to use via Settings -> Quick Settings). Also if you minimise the File system health section for J:\ in that screenshot you should see the Disk sectors section show an additional button in the left column of options, which (unless already scanning that disk) should be a blue button with a white triangle, which can be used to manually start a scan of that disk.

I suppose I can't rule out a haunted port, but I'd still place my monopoly money on door number two (drive belatedly self-corrected). Wondering, if you clear the blocks and rescan it does Scanner still find the same damage?

Hi Daxar. If you add a third drive but keep the duplication at x2, which drives any given file ends up on will depend on how you have the balancers set. The default set of balancers includes the Duplication Space Optimizer; its job is to optimize the pool to make the most use of your free spacefor duplicating files, so it will want to move some of the existing files to the third drive to free up space for more duplicated files.

Basically SMART errors can be divided into "it may fix itself" and "it won't fix itself". Neither is necessarily "replace it ASAP" but it's more probable with the latter. Seek error rate is with respect to how well the drive is moving the head(s) to the correct position and can change over time due to various factors (vibration, temperature, wear, etc). It is not usually by itself a sign of a failing drive (e.g. a consistently high seek error rate can indicate a defect that can't be compensated for but isn't ultimately preventing the drive from reading and writing data, just slowing it down). Drives can self-correct to an extent; if a SMART error pops up and then disappears shortly after and doesn't return, the drive's own logic has most likely taken care of it. E.g. in the case of seek errors, the drive may adjust parameters of the head movements to compensate. Scanner polls SMART frequently by default and thus it can often catch these temporary errors before a drive can finish self-correcting the issue. These temporary errors can also be due to circumstances beyond a drive's control (e.g. occasionally running hot due to high load or insufficient cooling, or something in the chassis is loose and causing vibrations) so it's still useful to know about. P.S. DrivePool's Scanner balancer plug-in has two tiers of whether to automatically evacuate, warnings (basically SMART has reported something to complain about) and damage (SMART is reporting there's something the drive can't fix or Scanner's own scans are finding damage).

Yes. I know at one point Chris mentions their pool had 26 drives in it, that was a while back. Glancing through the same thread another user's pool is 35 drives for example. I'm pretty sure I've seen screenshots of pools with ridiculous numbers of drives (40+) elsewhere in the forums but I can't remember where or exact numbers offhand. Theoretically DP can handle as many drives as Windows can support; the real limit is having good hardware. P.S. The trick with hardware RAID, zfs et al is you don't make one giant array, you make an array of smaller (three to six disks each) arrays. The pro is you can get things like parity protection, bitrot healing, stuff like that. The con is the extra micromanagement and how fiddly adding and removing disks can get. If you have a machine with good hardware RAID management you can have DrivePool do the pooling for all the small arrays so you can get the best of both worlds, but it's still something I'd only recommend planning out carefully.

If the drive is sufficiently bad, it may not be removable via the UI options while it's still physically connected to the machine. If you have duplication enabled for its content you can still physically remove it and then remove it in the UI, and DrivePool will reduplicate the content from and to the remaining disks. If you don't have duplication enabled for its content and don't want to restore from a backup you could manually copy that content to a spare or new disk (how well this works will of course depend on how it's going bad) before physically removing it so that you can reinsert the content back into the pool afterwards.

I would suggest opening a ticket with StableBit with what's happened and your workaround, hopefully they can both resolve it permanently for you and fix whatever the underlying cause is. Tagging @Christopher (Drashna) in the meantime.

Hmm. What happens if you run "dpcmd unignore-poolpart poolpartfullpath" for one of the "missing" disks? For example if you mounted one of the "missing" disks under the drive letter "M" you'd run something like (replacing the poolpart's folder name appropriately): dpcmd unignore-poolpart m:\poolpart.12345678-90ab-cdef-1234-567890abcdef Or if you had all of your poolpart disks mounted as folders under a physical disk instead of having drive letters of their own, it'd be something like: dpcmd unignore-poolpart e:\mounts\disk05\poolpart.12345678-90ab-cdef-1234-567890abcdef Does that disk come back? Just wondering if the unexpected restart in the middle of adding the new disks mangled the pool's part tagging.

The scanner plugin should since "Unless the drive is being emptied" is still ticked. The optimizer plugin I'm unsure of.

A1. It looks like it's based on the oldest scanned block. If you expand the drive (the + sign) it shows the sector scanning and you can see the date and time of when that happened to the upper right of the grid map, which at least on mine matches up. A2. The tooltip mentions that it's "only when disks have to be re-checked" and the tooltip for "unless disk scans are past due by" mentions it won't do anything until the disk has already been scanned at least once? A3. Could be Windows-related; I've had Windows insist a drive is in use even when Resource Monitor is saying there aren't any files open? Welcome to DrivePool and Scanner!

I think un-ticking "Balancing -> Settings -> File placement rules respect real-time file placement limits set by the balancing plug-ins." is what's needed? You want the VMs to be sorted into the 4TB SSD by the File placement rules more than you want them to be cached into and emptied out of the 1TB SSD by the SSD Optimizer plug-in, and perhaps without that un-ticking the SSD Optimizer might be ignoring the File placement rules when it's emptying the "SSD" disk into the "Archive" disks?

A found.000 folder (or found.001, found.002, etc) is a hidden system folder created by Windows via CHKDSK if it recovers file fragments after a crash, power loss, removing a drive too early, a disk going bad, etc. It contains .chk files, which can be lost files or parts of files. Sometimes CHKDSK can find old files/data that it thinks were lost when in fact they were purposefully deleted. It's safe to delete in the sense that doing so won't affect the current running of your system, but if your files are not all where they should be / intact you may want to keep it for recovery purposes. As for the other hidden system files/folders they should all be left as they are.

Hi Swindiff. If you try examining H: drive with WinDirStat 2.5.0 or higher (https://windirstat.net), in elevated mode, does it reveal anything hidden taking up space (e.g. System Volume Information) inside or outside the poolpart)?

That number is so crazily high I'd strongly suspect it to be a sign error or the like where the value is being read incorrectly from the drive. 1. Is there an option to Submit the drive's health to StableBit for analysis? If so I would use that. 2. If the drive is otherwise functioning normally, I would suggest selecting to use "Ignore warning..." and pick the option to only alert you if the value changes.

CloudDrive doesn't touch existing files in your provider. You have to move any files you want moved exactly as if it was an independent drive.

If you move files between existing folders that have different duplication levels then DrivePool will automatically adjust the duplication of those files. If you move folders between existing folders that have different duplication levels then DrivePool will automatically adjust the duplication of those folders (and their contents) unless they already have a specific duplication level set. E.g. if you have a folder T inside X2 that was simply inheriting X2's duplication level and you move it to X1 it will inherit the duplication level of X1 instead. E.g. if you have a folder T3 inside X2 that had it's own different duplication level of x3 and you moved it to X1 it will keep its duplication level of x3. Note that the File Protections option in the GUI color-codes folder duplication levels as dark blue if they are inheriting from their parent folder instead of light green if they have a specific duplication enabled or light red if they have duplication specifically disabled. (this is all assuming you're using the pool drive normally, not accessing the hidden poolpart folders directly)

It would've been the drivepool volume.

@Christopher (Drashna) Any ideas?

If you manually put a test file into that disk's poolpart and do a Re-measure, does it evacuate the file?

Hmm. Scanner checks by disk, not by volume, so I suspect an old trick where you split the drive into multiple partitions with the bad sectors in unallocated space won't work: Disk: |<- volume 1 -> <- unallocated space containing 8 bad sectors -> <- volume 2 ->| Only other option I can think of is telling Scanner to NOT scan the surface of that disk automatically (in Scanner GUI, click that disk, click "Disk settings" (has the three green horizontal bars next to it), tick "Never scan surface automatically", click Save) then expand the disk's entry so you can click on Edit blocks and select "Mark all Unreadable blocks Unchecked". Scanner should then still alert on any new SMART errors but it'll be up to you to remember to manually scan that disk from time to time.

Wouldn't work. For example, say our SSD drives are D and E and our HDD drives are F and G, so we pool D and E as S and then S and F and G as T and enable duplication on T. This effectively gets us D:\poolpart.SD and E:\poolpart.SE and S:\poolpart.TS (and thus D:\poolpart.SD\poolpart.TS and E:\poolpart.SE\poolpart.TS) and F:\poolpart.TF and G:\poolpart.TG - which means any data placed on S never goes on the HDDs (regardless of whether duplication is enabled). If you did it the other way (so the pool of HDDs is being added to the pool of SSDs) you'd at least get data placed on the SSD pool going on the HDDs sometimes but you wouldn't be able to guarantee that every file would end up on both a HDD and a SSD unless you started manually controlling it via (I suspect) a quantity of placement rules at least equal to the quantity of SSDs - which rapidly defeats the purpose of automating things simply. FWIW, I use the volume labels of the drives to indicate their position and serial. E.g. a drive's label might be cardC-portP-bayB-diskD. That way if I saw that all the drives whose labels began with card1 suddenly showed in the GUI as missing from my pool I'd have good reason to suspect there was a problem with that particular card.

Hi, the PoolPart.* folders cannot be renamed. You could create a shorter symbolic link or junction to a poolpart, but as it is generally not recommended to access poolparts directly (e.g. except for initial seeding) is there a particular reason you need to?

Just to explicitly confirm, you did then disable Read Striping and further attempts to re-rip and recopy have all been successful since?