Shane

Hi silk, my commiserations on having to deal with a borked recycle bin! You were close. The syntax of the ignore command is: dpcmd ignore-poolpart pooldriveletterwithcolon poolpartuid The syntax of the unignore command is: dpcmd unignore-poolpart poolpartpath For example, in your case above (assuming T is the letter of your pool drive - not your poolpart disk), to ignore that particular poolpart you would use: dpcmd ignore-poolpart T: 422717a2-17f9-4c2f-b66b-1227cf2442c0 While to reverse that, unignoring it, you could use: dpcmd unignore-poolpart \\?\Volume{c29fdf21-0f4b-41b9-9a1a-c540f54e1c28}\PoolPart.422717a2-17f9-4c2f-b66b-1227cf2442c0 (as for why DrivePool put the poolpart disk back into the pool after it was removed while missing, that's because when a missing disk is removed DrivePool can't make any changes to that disk to mark that poolpart as no longer in use - and normally the expected reason to Remove a Missing disk is because the disk is dead and won't be showing back up!)

Hi, if you've just created a pool by adding disks to it, any files that were already on those disks are not automatically moved into the pool.

If you create a free StableBit Cloud account you can link your installs/licences to it (in drivepool, look for the cloud icon to the top right of the app) and manage them from there (free allows managing up to eight devices).

It makes adjustments to your Balancing, it doesn't replace it. Its priority will depend on your settings and on how high it is positioned in the list of balancers.

Yes, you could just move your files out of the poolpart folders and then "Remove" the disks, that's correct. If you plan to reinstall DrivePool elsewhere, you should deactivate the license (either cog icon to top right -> Manage license, or cloud icon to top right -> Unlink) before uninstalling it.

It does seem suspicious that the problem affected the other drive only when you put it where the first one was placed, yes.

Hi! While you should always have a backup of your data (#obligatoryITcomment), DrivePool will automatically recognise a pool plugged in from another machine; note that your pool will retain duplication settings but not performance and balancing/placement settings, so you may wish to record the latter first. If your old server's drivepool license is managed locally rather than through stablebit cloud then you should deactivate it before uninstalling drivepool so that you can reactivate the license on the new install without potentially needing to request support.

Hi, your example screenshots have broken links. You can normally find the results of a chkdsk, that required a reboot, in the Windows Event Viewer. If the 0 byte files are appearing on other drives I would suggest running chkdsk on those as well (or just every drive). File table structures can be damaged without necessarily involving bad sectors; it can also be due to malware, loose/dirty connectors, bad RAM, dodgy controllers, Windows Update SNAFUs, power supply issues, etc.

Hi, I'd suspect either of: the program isn't requesting the data faster than just one of your NVME drives can supply it or the program is requesting data in a way that isn't triggering the striping algorithm. See https://stablebit.com/Support/DrivePool/2.X/Manual?Section=Performance Options for more details on what triggers read striping. You could test the feature by placing the 60GB file on a pool of slow disks (e.g. two SATA HDD or two USB HDD), with 2x duplication and read-striping enabled, then: Copying the file from the slow pool to a NVME target and observing the source reads (DrivePool should perform read-striping from both HDDs because each should be far slower than the NVME SSD target). This should confirm that striping is working as designed. Presuming #1 passes, performing your inferences using the file on the slow pool and observing the source reads. If it stripes then you have confirmed the bottleneck is the app. If it doesn't stripe then either the app's requests aren't enough to even saturate a slow drive or something strange is going on.

I'd suspect the 'Other' data is in the "$RECYCLE.BIN" and/or "System Volume Information" system folders in either "I:\" (physical disk root) or "I:\PoolPart.27099acc-9b43-4aff-8854-db05102694da" (poolpart root). As those are folders that have both of the System and Hidden attributes set by Windows they don't show up if you've only set Hidden items to be visible, you have to set System items to be visible as well. Some disk measuring utilities (e.g. current versions of WinDirStat and TreeSize) can be run as Administrator to show the actual size and contents of System attributed folders (some utilities can't do this). I also notice that the poolpart in I: drive doesn't have the Hidden attribute set; normally this only occurs to poolparts that have been removed from a pool.

Scanner notifies DrivePool as soon as it detects the problem. If you only check the box later, I'd guess it might trigger on the next time Scanner checks the drive and finds it is still bad and notifies DrivePool again and/or the next time DrivePool does a balancing check (whether scheduled or manual).

Assuming it's a complete download of a clouddrive folder from OneDrive, either you could upload a copy of the folder back to a OneDrive account and reconnect to it there or you could convert it (but make a backup first just in case) to a LocalDisk format using the CloudDrive.Convert.exe tool that comes with CloudDrive and reconnect to it locally. If it's only a partial download I don't know how well either would work (might depend on how much is intact); if the data is critical I'd suggest opening a support ticket with StableBit via the contact form for technical support. Note that if encryption was enabled for the clouddrive then you would also need to have the phrase or key that was chosen for that clouddrive (if the option to automatically unlock the drive on boot was used, this may still be recorded in the computer originally used to access the clouddrive).

Hi Bear, keep it safe for work please. Re the bad drive does it still have the same problem if you switch it around with another drive's bay in the machine? Re your pool doing a re-measure every time you reboot the machine - if it's a hard reboot rather than a Windows shutdown/restart then that's a safety precaution. If however it is still doing the re-measure after a normal Windows restart then it might be a problem with how quickly your drives are powering up / being recognised by the OS. Re the "Pool" versus "Folder" duplication, the difference is "Pool" sets duplication for every file in the pool (so every file is not duplicated, or every file is x2 duplicated, or x3 or whatever) while "Folder" sets duplication for files per-folder (e.g. if you wanted to have files in one folder at x2 duplication and files in a different folder at x4 duplication or whatever). Also only 10 days from Monday next week til Christmas? It's still October!

Based on this thread I believe DrivePool isn't "measuring" the VM as duplicated or not while it's open for writing; if you stop the VM you should see it show up as Duplicated instead of Other. That thread also indicates that VMs should be fine when using (real-time) duplication.

Yes. Still, it's always a good idea to initially (and occasionally) test that any redundancy/backup method is actually doing what it's meant to do, so I do recommend using Everything or similar to see if your files are indeed going where they're supposed to when they're supposed to. I know from personal experience that discovering "oh, the backups I thought I had stopped working a month ago" is not a good feeling!