Shane

At one point in time I had the same configuration.  In my case the answer was YES.  When the one drive failed, I was able to remove it and my pool saw NO lose of data.  A little rebalancing was required but in the overall situation nothing was lost.  I would suggest you keep the Mirror and multiple duplication on JBODs.  A NAS can lose a little if multiple disks fail because of power bounces but if you keep a UPS online with the protections you will be fine.

Duh, that was it, thank you!

As per above "T" has to be the pool's drive letter, not the poolpart disk's drive letter.
So if your pool drive letter was instead "P" then you would use:
dpcmd ignore-poolpart P: 422717a2-17f9-4c2f-b66b-1227cf2442c0

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

I figured it out. it was a poblem on the aws side. sorry. 

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! 

Excellent! So the basics at least of my strategy make sense and should work fine as long as the  #1 Ordered File Placement duplicate-only drive doesn't overflow?
Since my OneDrive storage limit is 1TB anyways I am thinking of upgrading the SSD to 1 TB to match. Worse comes to worse if I ever outgrow the 1TB I will switch to a HDD and rethink my cloud provider, but OneDrive is free as part of my Office365 subscription so I am using that for now since it doesn't cost anything extra.
My NAS is my old Synology I outgrew that I am planning to sync to. I will probably enable snapshots so I can rollback files on the NAS if I want to add file versioning. If I have more money, maybe down the road, I can add a 2nd remote Synology as a HyperBackup endpoint so I stop counting my working files as one of the "3" in 3-2-1.

I think that did the trick.

Nope, I still haven't figured it out, but it's not DrivePool. I can reproduce it on Firefox and forks (LibreWolf) of Firefox when running simultaneous downloads to a network share. I see it on completely different machines too, not even to my DrivePool machine, so it's not a problem on that machine. I'll have to try another browser and see if I can reproduce it there.
 

I was able to remove the device after using the 2nd and 3rd commands.
The disk still exists in File Explorer but I get the below error when trying to access anything on the drive.


After re-reading both of our messages I believe I may have been mistaken and this is actually a secondary M.2 Drive and the one I unplugged was a sata drive missing the power cable already so not in use. I'll look to see if it is an M.2 if the issue returns as it's a pain to get to in my case if it is installed.

I appreciate your help regardless!

Sorry - just saw this.  Didn't have a chance to try this, but Chris suggested using the ignore checksum setting and that solved the problem

Than you for this. The drive was purchased new in 2016 so amazingly its still under warranty. I setup the Samsung Magician software but all the diagnostic options are not compatible with this drive. I use this drive for the OS on my server so its not really storing critical data but if it were to die suddenly that would suck. Will see if I can cover it under warranty but will most likely replace it either way. Thank you for the help!

I think I found the answer to my issue here:
 
I'll try this out and see how it works.

Thanks @Shane. This problem appears to be resolved.  There was a folder with over 4 million tiny log files that seemed to be tripping up the measuring process.  I got rid of that and everything completed. 

Hey, thanks for the update anyway! Could also try setting a File Placement rule to balance all of the HD2 files into just one of the pool's drives?

Hi! Yes, you can perform an intra-drive "move to new location" operation instead of an inter-drive "copy to new location and delete from old location" operation.
This is called seeding and the official wiki article is here. However my advice is to create a temporary unique* folder in each drive's hidden poolpart folder and move your data into that folder rather than just into the poolpart folder itself, and THEN access those folders via the pool drive to move them from there to wherever you want their final position to be and then delete the temporary unique folders. This reduces the risk of accidentally overlapping any data. I also don't reset DrivePool's settings store afterwards; instead I use Manage Pool -> Re-measure and Cog (upper right) -> Recheck Duplication in the GUI.
* so different names on different drives, that didn't already exist on the pool, e.g. on drive D you might create d:\poolpart.1234\seedtemp.d\ while on drive E you might create e:\poolpart.5678\seedtemp.e\ and so forth.

I'd never changed the default order of the balancers. Bumping the SSD balancer to the top seems to have fixed it.
 
I do not have any file placement rules in place.

To move a pooled disk, and the pool data stored on that disk, between pools without having to perform a copy-off copy-on is indeed possible:
Assuming "p:" is the old pool and "q:" is the new pool and "d:" is the disk to be moved, Assuming "d:\poolpart.1" is the current hidden poolpart folder and "d:\poolpart.2" will be the new hidden poolpart folder, Create a new folder in "d:\", e.g. "d:\holdingzone", that does not match any existing folder in "q:\". Close the DrivePool GUI (if it is open) and stop the DrivePool service. Move the contents of "d:\poolpart.1" into "d:\holdingzone", excluding the "cove.fs", "$RECYCLE.BIN" and "System Volume Information" folders. Start the DrivePool service and open the DrivePool GUI. Remove the disk from the "p:" pool. If successful, this will also either remove the "d:\poolpart.1" folder or leave it visible for you to remove manually. Add the disk to the "q:" pool; this will create the hidden "d:\poolpart.2" folder. Move the entire "d:\holdingzone" folder into "d:\poolpart.2" so its path is now "d:\poolpart.2\holdingzone". Do not move just the contents of the folder; move the entire folder. In the DrivePool GUI, for both pools do a "Manage Pool -> Re-measure..." if such has not already started. Now you can move the content of "q:\holdingzone" elsewhere within the pool "q:" if/as desired. Notes:
Ensure you are performing the above steps as a user with full access to all disks and folders (e.g. an Administrator) and with the ability to see hidden/system folders enabled. The steps may need to be adusted if you are using hierarchically nested pools (i.e. you have added a pool as a disk to another pool). Step 9 ensures that you don't accidentally overwrite anything in pool "q:", including any pre-existing folder duplication settings or other hidden pool metadata. Depending on your balancing/duplication/placement settings, there may be empty folder structures left behind in the "p:" pool - check that they're actually empty before you manually remove them as if not their content is on other disks still in the "p:" pool. If manually attempting to remove the old "d:\poolpart.1" folder in Step 7 warns you that it requires Administrator access despite you already being an Administrator, you may need to open a Command Prompt run as an administrator and execute the following commands: "takeown /f d:\poolpart.1 /a /r /d y" "rd /s d:\poolpart.1"

Having spoken to @Christopher (Drashna) via the Support page, ticking the IgnoreChecksum (under SMART) seemed to be the way to get it to work
Note that it takes about 30 seconds to a minute for the SMART information to start appearing in Scanner, so just wait a short while after making the change before doing anything else. No need to restart the Scanner service or reboot, from my experience.

Hi, when you use the Remove function of DrivePool on a disk that is part of a pool it proceeds to move the contents of that disk's poolpart folder to the other disks in the pool, so long as those other disks have enough room, after which the disk can then be safely physically removed. It will normally ensure that all duplicated files remain duplicated as part of this process unless you tick Remove's "Duplicate files later" option (in which case it might move the files and then find out there isn't enough room to re-duplicate them, but that can be desirable in certain situations).
For example if you started with an unraid "array" of one disk you could:
Move enough files from pool to array to have a disk's worth of free space in the pool. Remove a disk from the pool. Add the disk to the array. Repeat steps 1-3 until all of the disks have been removed from the pool and added to the array (obviously when you get down to one disk the pool won't be able to do duplication). 

Okay I figured out the issue. The problem was I was on DrivePool version 2.3.12.1683 and the in-application update check was broken. manually downloading and installing 2.3.13.1687 resolved the issue and allowed me to create the top level drive.

Hmm, in theory even if it's duplicating the metadata to other drives, it should still prefer to read from the fastest drive - but that presumes the metadata gets written to a SSD in the first place. Looks like forcing it can't be done from the GUI.
@Christopher (Drashna) does DrivePool internally prefer SSDs when it decides where to place the [METADATA] folder(s)? If not, can that be added as an option to DrivePool?
Actually, that would be a useful GUI-definable option to add to the Manage Pool -> Balancing -> File Placement -> Folders/Rules -> File placement options dialog in general, between the "New drives" and "Overflow" sections:
Preference -----------
  [✓] Prefer fast drives from those selected (e.g. SSD)
  [✓] Prefer slow drives from those selected (e.g. HDD)
  (i) If both or neither are selected, no preference will be made.
with the [METADATA] folder also visible and customisable here instead of being hidden (perhaps lock the other options for it).

Go to My Computer, or My PC Icon, if you have the icons turned on, on your Desktop Screen. Right click on it and select more option. And click on manage.
In the Computer Management Window you will see Disk Management. Click on that and all your hard drives will show up. Select one of the drives and right click.
You will see Change Drive Letter and Paths. Click on that. Select remove. You will get a warning. But that's ok if the hard drive is only for storing data. (Videos, documents and pictures. Stuff like that).
No programs installed on the drives or looking for a drive letter to work. ( Just Data Storage. StableBit will still work. It does not use the drive letters to function properly).
If later you need to access that drive or drives outside of the storage pool. Just do the same thing and click add instead of remove the drive letter.

Have tested files stored in a CloudDrive (v1.2.12.1836) drive mounted on a DrivePool (v2.3.12.1683) pool; fileID (and objectID) is stable and persistent until the file is deleted.
So you can safely use a clouddrive on top of a drivepool with respect to this bug.
Pros: a fully NTFS-compliant drive that pools the capacity of multiple physical disks, would even let you write a file bigger than the capacity of any individual disk!
Cons: slower than using drivepool directly, content is not readable directly from the physical disks, may need to be manually resized to take advantage of additional disks (or if disks are to be removed), some or all of the clouddrive may become unreadable if X disk(s) is lost unless (the clouddrive folder in) the pool is duplicated at an X+1 multiplier.
Kind of like a software RAID that has no ECC but can still survive a certain amount of disk failure(s) and unlike a normal RAID can let the user safely add and remove disks?

No, it dosen't have any preference.  But if you have read striping enabled, it should use that to optimize the reads.  
However, you might be able to use the file placement rules to hack this.  Eg, add a rule for "\.covefs\*" should work (or at least, dosen't error out).  This should allow you to specify a drive (and testing this, it looks to be respected)