Shane

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.

Thanks for the clarification.
Just wanted to point out that I'm not asking for an implementation. I'm just looking for clarification of what is implemented. I understand DrivePool is not RAID. I'm making a statement that other redundant filesystems do offer healing and that DrivePool could implement a version of it.

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.

While chasing a different issue I noticed that my Windows Event logs had repeated errors from the Defrag service stating  "The storage optimizer couldn't complete defragmentation on DrivePool (D:) because: Incorrect function. (0x80070001)".  Digging further, I found that the Optimize Drives feature had included the pool's drive letter in the list of drives to optimize. It has also listed the underlying drives in the pool, but that should be OK
To remove the drive pool from optimization, open Disk Optimizer, in Scheduled optimization, Change Settings, then Choose drives, and then un-select the pool drive.
See https://imgur.com/PB2WPH0
 
 
 
 

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.
 

i would add that, the most sensible option is as Shane said DP will ask... fix it yourself.
long ago when i was experimenting with pool duplication, there was a conflict between 2 movie files on my drives.  when DP popped up and asked me what to do, i left the question/notification/error box sitting there...  i went to the underlying DP drives and compared the 2.  it was the NEWER version that was corrupt and would not play.  moral of the story:  always check it out for yourself.
cheers

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

That's correct.

That's the nice trick thank you !
So the best way of manually drag & dropping to poolpart is
1.stop the service
2.create a unique non-conflicting folder that doesn't have the same name in across every drives in pool
3.drag and drop there
4.restart the service
5.re-measure  
just this right ? 
and additionaly if I use duplication option 
I do this extra step : Troubleshooting -> Recheck Duplication at the top of the toolbar

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

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.

All my drives are installed inside the server chassis, so I'll just remove the HBAs which will have the same effect. Reading back through many, many old posts on the subject, I believe I've been looking at this all wrong. The actual information Drivepool uses to build and maintain the pool is stored on the pooled drives, not on the system disk, so its just a matter of reinstalling Drivepool and it goes looking for the poolpart folders on the physical drives in order to rebuild the pool. I'm not sure why I've been thinking I needed to worry about what was on the C: Drive, other than that's where I placed the junctions for the drives on my system, but that seems to be more of a housekeeping feature to get around the 26 drive letter limit more than anything to do with Drivepool itself. If this is correct, I believe I'm ready to go.
It would seem that Stablebit Drivepool is quite a feat of engineering.
 
Thanks again Shane.

I also use Snapshot Raid with Drivepool.  If a drive failure, I physically remove the drive, THEN remove it on Drive pool.  Install a new drive, put it in the pool and restore. 

Sorry, should also mention this is confirmed by StableBit and can be easily reproduced.   The attached powershell script is a basic example of the file monitoring api.  Run it by "monitor.ps1 my_folder"  where my folder is what you want to monitor.  Have a file say hello.txt inside.   Open that file in notepad.     It should instantly generate a monitoring file change event.  Further tab away from notepad and tab back to it, you will again get a changed event for that file.  Run the same thing on a true NTFS system and it will not do the same.
You can also reproduce the lack of notifications for other events by changing the IncludeSubdirectories variable in it and doing some of the tests I mention above.
watcher.ps1

So this is correct, as the documentation you linked to states.  One item I mentioned though, is the fact that even if it can  be re-used if in practice it isn't software may make the wrong assumption that it won't.  Not good on that software but it may be a practical exception that one might try to meet.  Further, that documentation also states:
"In the NTFS file system, a file keeps the same file ID until it is deleted. "
As DrivePool identifies itself as NTFS it is breaking that expectation.
I am not sure how well things work if you just disable File IDs, maybe software will fallback to a more safe behavior (even if less performant).    In addition, I think the biggest issue is silent file corruption.  I think that can only happen due to File ID collisions (rather than just the FIle ID changing).   It is a 128 bit number, GUID's are 128 bits.  Just randomize the sucker the first time you assign a file ID (rather than using the incremental behavior currently).  Aside from it being more thread safe as you don't have a single locked increment counter it is highly unlikely you would hit a collision.  Could you run into a duplicate ? sure.  Likely? Probably not.   Maybe over many reboots (or whatever resets the ID's in drivepool beside that) but as long as whatever app that uses the FileID has detected it is gone before it is reused it eventually colliding would likely not have much effect.   Not perfect but probably an easier solution.  Granted apps like onedrive may still think all the files are deleted and re-upload them if the FileID's change (although that may be more likely due to the notification bug).
Sure.  Except one doesn't always know how tools work.  I am only making a highly educated guess this is what OneDrive is using, but only made this after significant file corruption and research.  One would hope you don't need to have corruption before figuring out the tool you are using uses the FileID.    In addition, FileID may not be the primary item a backup/sync tool uses but something like USF may be a much more common first choice.  It may only fall back to other options when that is not available.
Is it possible the 5-6 apps I have found that run into issues are the only ones out there that uses these things? Sure.  I just would guess I am not that lucky so there are likely many more that use these features.
 
I did see either you (or someone else) who posted about the file hashing issue with the read striping.  It is a big shame, reporting data corruption (invalid hash values or rather returning the wrong read data which is what would lead to that) is another fairly massive problem.    Marking good data bad because of an inconsistent read can lead to someone thinking they lost data and trashing it, or restoring an older version that may cause newer data to be lost in an attempt to fix.  I would look into a more consistent read striping repro test but at the end of the day these other things stop me from being able to use drivepool for most things I would like to.

So this is weird.
A complete uninstall including registry entries and Drivepool's program folder with Revo Uninstaller followed by fresh install with 2.2.5.1237 works with expected speeds.
Installing latest version 2.3.3.1505 over that goes back to 5mb/s.
A standard uninstall using Windows of 2.3.3.1505 and rolling back to 2.2.5.1237 continues to be 5 mb/s
Doing a complete uninstall with Revo and reinstalling 2.2.5.1237 again allows it resumes working at expected speeds.
I'm testing by using a folder with a 15gb video file and mixed smaller files and bouncing it between drives using a folder placement rule.  I also tested using a 500gb solid file. Only on a clean 2.2.5.1237 installation am I able to get expected speeds.
So it seems like at at some point something changed that negatively affects transfer speeds and persists unless you completely uninstall it from your system.
Anyway, going to try a different version next.

Edit: Tentatively 2.3.2.1493 seems to work well. I will update if anything changes.
Edit2: Nope, started noticing the same behavior. Worked my way back to 2.3.1.1448 and still getting slow speeds on re-balancing. It takes a really long time to reinstall, recheck drives, test balancing so I'm back to the latest version now as 2.2.5.1237 is missing a lot of the functionality of the later releases. I'm hoping a future update changes something. This is with unduplicated files. SDD to HDD balancing caps at 5mb/s and SDD to SDD balancing caps at 40 mb/s.
Edit3: Alright so I feel like an idiot but it looks like my SSD drives were running on a USB 2.0 interface and not a USB 3.1 despite it being in the same enclosures as my HDD which were all 3.1 per USBTreeView. I remember checking this before and the SSDs were running at 3.1 Superspeed. I think this is also why the 'fix' of swapping to a different Drivepool version stopped working because  at some point they downgrade to USB 2.0 and the transfer speed plummets. I don't think this has anything to do with Drivepool but wanted to throw this edit out there to save someone a bunch of misplaced effort. Anyway, not sure if its an enclosure issue (Mediasonic Probox, have used a handful and they have always worked well) or windows, but I reinstalled the drive drivers and reseated them so I'll see.
 
 

you could make two partitions, one 16TB partition and an additional 380GB partition. And add both of those to the pool, but yes anything beyond 16TB exactly, will not allow 4k cluster size. and 4k cluster size is required for compression.

you should have no problem doing that.
however with the MBR partition limit it will limit you to a maximum partition size of 2.2TB on your boot drive. the rest will be "free space" in Disk Management. you are better off getting a 2TB drive (which will have no waste) or 3TB (only wasting ~600GB after TiB to TB accounting)

realistically though all that Drivepool cares about is that they are the same filesystem, (IE NTFS vs ReFS)

cluster size, 4kn vs 512e, and MBR vs GPT. even multiple partitions on the same disk, all don't matter to Drivepool as those are a few layers below it.

hello.
i don't know what the solution to your issue might be, but i do know that the AIO plug-in is outdated.  the code is old and one of the plug-ins (Drive Space Equalizer) it was originally designed to replace has been updated so... using the AIO may cause conflicts .
see here for a bit more info:
https://community.covecube.com/index.php?/topic/12857-all-in-one-plug-in/#comment-45314
 
if i were in your place i would consider disabling the AIO.  until the original programmer @methejuggler gets around to updating his code or @Alex will actually do something about this issue it seems more of a liability than any kind of enhancement.
tl;dr:  your plugins are banging heads.
all this said, i would wait for an 'official' reply from Shane or Christopher before attempting anything drastic.  just my .02 cents
cheers
 

Hmm... I had not thought of backing up the actual physical drive since I have them hidden with no drive letters. And yes... I have 4x drive duplication enabled and the drives should be an exact copy of each other. So if I understand correctly, I can just pick any of the 4 drives and back that up to Backblaze B2, correct? So I would not even need to use cloud drive. I think that would be the perfect solution. Thanks for your help!

Based on my own experiences, neither. Likely it means the drive's own firmware found something wrong (thus the S.M.A.R.T. flag) and then dealt with the problem itself, it's just that Scanner noticed the warning inbetween detection and resolution.
You might find further info in the logs (C:\ProgramData\StableBit Scanner\Service\Logs), or if you enable Scanner's email notifications and it happens again the email would mention which particular S.M.A.R.T. warning/error occurred.
As I use both duplication and nightly backups I'd just double-check that those are on and wouldn't worry about it; I'd only consider replacing the drive if the issue kept happening (more) often or became a permanent error rather than a temporary warning. YMMV.

Yes, that's the pool drive letter. So if the hidden poolpart folder in the root of your bad drive is named "PoolPart.654e1b5c-05b8-44a2-8b6b-a0251f2ec7d6" then the command you would use to tag that particular poolpart to be ignored would be:
dpcmd ignore-poolpart n: PoolPart.654e1b5c-05b8-44a2-8b6b-a0251f2ec7d6

Have not heard back from Stablebit support yet, but was able to resolve the issue.  Apparently one or more of the drives had a corrupted $RECYCLE.BIN folder that was causing the error.  Just deleted all the recycle bin folders off all the drives, rebooted and now everything is working perfect.  hopefully if anyone else has a similar problem in the future this will help you.

Did some looking. AFAICT there's no official DP method (command-line or GUI) to gracefully offline a pool. Tagging @Christopher (Drashna) ?
What I have so far found seems to work, with a bit of experimentation today, was the following:
1. Ensure that all relevant poolpart volumes appear to Windows as ejectable drives, then set the override for CoveFs_IsDiskRemovable to true and restart Windows; the pool drive composed from those volumes should now itself show up as an ejectable drive (but doing so via the Windows GUI will just have DrivePool immediately redetect and remount the pool).
2. In your batch file the command diskpart /s scriptfile.txt should now* be usable to take the pool offline where scriptfile.txt is the name of the file containing the following text (replacing pooldriveletter with the letter of your pool drive):
   SELECT VOLUME pooldriveletter
   OFFLINE VOLUME
3. If the command was successful then the errorlevel for the diskpart command should be zero (if you need to check for that in your script) and the designated pool should gracefully disappear from DrivePool; you should then be able to eject / depower the relevant physical drives.
I might still recommend using DrivePool_RunningFile to ensure that DrivePool isn't in the middle of any maintenance operations, as I don't know if interrupting those in this manner would cause DrivePool to want to recheck the pool, but if you find it doesn't then I guess it won't be needed!
How are you scripting the JBODs to power on/off?
*I found that using diskpart to offline a non-removable pool drive would sometimes crash diskpart/drivepool/windows so I don't recommend trying that.

Windows obtains the removability status from the hardware, so I'd suggest checking the documentation for the HBA to see if there's a internal setting or manufacturer utility to mark the drives/buses as hot-pluggable.
(There did indeed used to be such a key and yeah Microsoft removed it for their ineffable reasons.)
You might also try this piece of software http://mt-naka.com/hotswap/index_enu.htm as it does have command line functionality - but it may not support your hardware. Also, disclaimer, I haven't tried it myself; proceed with caution.