Shane

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

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

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!

From a Command Prompt run as Administrator, try:
fsutil reparsepoint delete x:\Inbound It should become a normal, empty folder which can then be deleted normally (although it may have the read-only attribute set).
If that doesn't work it's possible NTFS's gotten mangled in one of the poolparts; rather than doing it at the pool level you might have to try doing the above in every hidden poolpart folder that has an instance of the junction (stop the DrivePool service first, start it again after).

Hi, if you open the Resource Monitor tool in Windows, click the CPU tab, and in the Associated Handles section use the Search Handles field to enter a path (e.g. "p:\") it will show you all file and folder handles in use within that path and what is using them.
You may need to check each physical disk in the pool rather than just the pool drive.
There is also this command available, which needs to be entered in a Command Prompt run as an Administrator, where "p:\" is the drive letter of the pool followed by a colon and blackslash:
dpcmd force-close-open-files p:\ Obviously, don't use it if you do have any files open at the time that you want to stay open.

A drive showing up in the pool despite being physically disconnected is bizarre and impressive!
Before calling for the Ghostbusters:
if you haven't already tried restarting the computer, go into Windows Services and try restarting the StableBit DrivePool service if that didn't help, restart the computer if that didn't help, try: open a Command Prompt as an Administrator and enter dpcmd refresh-all-poolparts if that doesn't help then try, where "p:" is the pool drive letter followed by a colon dpcmd list-poolparts p: this should give you a list of the pool's parts by their global paths find the PoolPart that corresponds to your ghost disk and copy its particular "PoolPart.unique-identifying-string" name. enter the following but with the appropriate pool drive and PoolPart name: dpcmd ignore-poolpart p: PoolPart.unique-identifying-string this should hopefully tag the ghost disk to be ignored by DrivePool, but it normally does require the target to exist so I don't know if it'll work! If none of the above works... you may have to try resetting DrivePool on that machine (so if you have any custom balancing settings or placement rules you want to keep, write them down first before doing that).

Try running the following in a command prompt run as administrator:
dpcmd refresh-all-poolparts And where poolpartPath is the full path of the poolpart folder of the missing drive:
dpcmd unignore-poolpart poolPartPath for example, dpcmd unignore-poolpart e:\poolpart.abcdefgh-abcd-abcd-abcd-abcdefgh1234 And where volumeid is that of the "missing" drive (you can use the command 'mountvol' to get a list of your volume identifiers):
dpcmd hint-poolpart volumeid for example, dpcmd hint-poolpart \\?\Volume{abcdefgh-abcd-abcd-abcd-abcdefgh1234}\ while poolparts and volumes happen to use the same format for their identifying string they are different objects If that doesn't help, you may try one or more of the following, in no particular order of preference:
repairing DrivePool (windows control panel, programs and features, select StableBit DrivePool, select Change, select Repair) uninstalling, rebooting and reinstalling DrivePool (may lose configuration but not duplication or content, and keep your license key handy just in case) resetting the pool (losing balancing/placement configuration, but not duplication or content):  Open up StableBit DrivePool's UI. Click on the "Gear" icon in the top, right-hand corner. Open the "Troubleshooting" menu, and select "Reset all settings..." Click on the "Reset" button. Alternatively, you may try manually reseeding the "missing" drive:
if - and only if - you already had and have real-time duplication enabled for the entire pool and you just want to get going again ASAP: remove the "missing" drive from DrivePool quick format it (just make sure it's the right drive that you're formatting!!!) re-add the "missing" drive, let drivepool handle re-propagating everything from your other drives in the background. otherwise: open the "missing" drive in Windows File Explorer (or other explorer of your choice) find the hidden poolpart.guid folder in the "missing" drive rename it from poolpart.guid to oldpart.guid (don't change the guid) remove the "missing" drive from DrivePool if the "missing" drive is now available to add again, proceed to: re-add the "missing" drive move all your folders and files (but not $recycle.bin, system volume information or .covefs) from the old oldpart.guid folder to the new poolpart.guid folder that's just been created tell the pool to re-measure once assured everything is showing up in the pool, you can delete the oldpart.guid folder. else if the "missing" drive is still not available to add again, proceed to: copy your folders and files (but not $recycle.bin, system volume information or .covefs) from the old oldpart.guid folder to the pool drive duplicates of your folders/files may exist on the pool, so let it merge existing folders but skip existing files you may need to add a fresh disk to the pool if you don't have enough space on the remaining disks in the pool check that everything is showing up in the pool if all looks good, quick format the "missing" drive and it should then show up as available to be re-added.

You should be fine. DrivePool identifies poolpart drives by the data internal to each drive, not their position on a controller. Basically so long as Windows can find and read the drives (e.g. they show up in Disk Management as basic NTFS volumes), so too should DrivePool.

That's fine. The thing to avoid is any risk of recursion - e.g. if you've got a drive mounted as a path on another drive, never add the latter drive to a pool that includes the former drive. So in this case you should make sure you never add your C:\ drive as a disk to either pool.

Hi Expo,
Where it says "Manage Pool" (about halfway down, left side), click that and then "File protection" and then "Folder duplication".

If you're reinstalling on the same hardware it should recognise your existing Activation ID. If it hasn't done so, you can use the ID you originally received from StableBit. If it returns an error, you should contact StableBit (select Support -> An issue with licensing) supplying the email address you used to register and they can resend it.
You can also, or may already have, linked your Activation ID to a StableBit Cloud account, in which case you can find it there.

"I have 4x 2TB nvme SSDs and 1x 4TB SATA SSD in one pool. Ideally, I'd like all my files to be balanced evenly across the 4x nvme disks, and the duplicates stored on the SATA SSD. Eventually, I plan to add another 1x 4TB SATA SSD to equal the total volume of the 4x nvme disks, but for now that's not necessary for the amount of storage my files are taking up."
Hi GoreMaker! If this is the goal I would be recommending a multi-pool arrangement, not the SSD Optimizer - the latter is intended for using faster disks as cache rather than  as storage and will want to empty the NVMe disks to fill the SATA disk(s).
Example #1 (let drivepool handle the duplication and the deciding of whether user IO will be to/from your NVMe or your SATA disks):
Create a pool (let's call it N) and add your 4 NVMe disks to it. Set this pool's balancing to evenly distribute via the Disk Space Equalizer plugin. Create a pool (let's call it S) and add your 1 SATA disk (and later, the second SATA disk) to it. Set it as above. Create a pool (let's call it P) and add your pools N and S to it. Set it to x2 duplication. You can now put files on P and they will be evenly distributed across your NVMe disks with their duplicates distributed on your SATA disk(s). Example #2 (you decide whether user IO will be to/from your NVMe or SATA disks):
Create a pool (let's call it N) and add your 4 NVMe disks to it. Set this pool's balancing to evenly distribute via the Disk Space Equalizer plugin. Create a pool (let's call it S) and add your 1 SATA disk (and later, the second SATA disk) to it. Set it as above. Set up a scheduled task or similar to mirror the content of your N pool to your S pool (e.g. robocopy N:\ S:\ /mir /dcopy:dat /xa:s). You can now put files on N and they will be mirrored on S whenever the task runs. Or you could set up a two-way sync via third-party utility if you wished to have N and S synchronising bidirectionally.

Good to see. I'd suggest opening a ticket with StableBit to report your WinDbg analysis of the BSOD with 2.3.11 and that reverting to 2.3.8 stopped it, in case it's useful / they can ask for the dumps from the crash to trace the problem.

Hi David,
DrivePool does not split any files across disks. Each file is stored entirely on a disk (or if duplication is enabled, each copy of that file is stored entirely on a separate disk to the others).
You could use CloudDrive on top of DrivePool to take advantage of the former's block-based storage, but note that doing so would give up one of the advantages of DrivePool (that if a drive dies the rest of the pool remains intact); if you did this I would strongly recommend using either DrivePool's duplication (which uses N times as much space to allow N-1 drives to die without losing any data from the pool, though it will be read-only until the dead drive is removed) or hardware RAID5 in arrays of three to five drives each or RAID1 in pairs or similar (which allows one drive per array/pair to die without losing any data and would also allow the pool to remain writable while you replaced the dead drive).

C:\Windows\System32\dpcmd.exe
You should access it by opening a Command Prompt, run as Administrator, and simply entering "dpcmd" or "dpcmd [command] [parameter1 [parameter2 ...]]" where "[command] [parameter1 [parameter2 ...]]" are what you're wanting it to do (and you'll get the list of those options by entering "dpcmd" by itself).

Yes, that should be safe.

I think you'd need to use hierarchical pools. Something fairly simple like:
Pool A = Pool B + Pool C where Pool B = all SSD and Pool C = all HDD; Pool A duplication x2 but not real-time; Pools B and C duplication off.
DrivePool should be able to detect that B is all SSDs and prefer it for reading and writing, and duplication happens nightly (as per settings.json file; default 2am) when not real-time. Note that "prefer" doesn't mean "guaranteed" however.
But if you wanted to get a bit more clever, you could have something like:
Pool A = Pool B + Pool C where Pool B = all SSD and Pool C = one SSD + rest HDD; Pool A duplication x2 real-time; Pools B and C duplication off; Pool C have SSD Optimiser enabled with the SSD as the cache and the Automatic balancing set to empty the cache to the archive HDDs nightly (or whatever).
DrivePool would then be duplicating in real-time but still at SSD speeds, at least unless/until you filled the cache SSD (which would empty nightly or whatever), it should still prefer the all SSD pool B for reads, and even if it read from the pool C with HDDs it might still be reading (new files) from that pool's SSD cache.

It's controlled by FileDuplication_DuplicateTime in C:\ProgramData\StableBit DrivePool\Service\Settings.json and defaults to start at 2am; if you wish to have a different start time, use the Override and replace the null with your preferred value (e.g. "05:00").

Hi varied, DrivePool will identify the two pools as being different and connect to each of them as two separate pools on the new PC.
There is no built-in command to merge pools (yet) but it can be done manually.

While files and folders in a pool will still show their size (and also their "size on disk") as if they were not duplicated, DrivePool calculates the total, used and free space on the basis of the actual physical drives' total, used and free space; it does not attempt to predict space on the basis of duplication (e.g. that if you have x2 duplication on the entire pool you'll of course be using x2 as much space for each file). This is because of the problem of it being impossible to predict post-duplication free space when using per-folder duplication.

Hi Kenny, yes that'd be the method to use.
Based on the last time I did that, the process should be:
Install the DrivePool and Scanner on the new system. Start them in trial mode. Make a record of your automatic balancing schedule (if any) and your Balancer plug-in settings (e.g. which Balancers you are using and what their priority and configurations are) on your old system. Make a record of your Scanner settings on your old system (if desired). Turn off automatic balancing (if any). Shut down both systems, pull your pool drives from the old system and put them in the new system, then start the systems back up. All your pool's content, balancing settings, duplication settings and placement rules should be there. Redo your Balancer plug-in settings on the new system. Turn back on automatic balancing (if any). Configure your Scanner settings on your new system as desired. Once you're happy with everything, transfer the licenses.

As the old thread explains, DrivePool uses *.copytemp files in the process of balancing/duplicating files; if DrivePool is interrupted (e.g. power outage) during balancing/duplicating then both the original file and the temporary file.copytemp will remain. You can thus safely delete any *.copytemp files without losing data if DrivePool is not currently balancing or duplicating when you do so, and doing so will free up space occupied by the pool.
(technically, a copytemp file from a previous balancing/duplication would be safe to delete during a current one, but as there's no easy way to distinguish between such it is best to wait until the current one completes)

If you are looking for a list of forum admins, then from the community.covecobe.com main page click Browse -> Staff.
Alex and Christopher are the StableBit staff/admins, while Shane (myself) and saitoh183 are volunteer moderators. You can message any of them from the above page. I'd suggest Christopher first for general official responses/statements, myself if you just want some help re something on the forum?
You can also contact StableBit re product sales/issues/feedback/development or the like via the Contact form.

Depends on what you mean by clone (and presuming the drive lasts long enough to clone everything on it).
If you're cloning the whole drive, then you'll want to stop the drivepool service while both are connected or clone it on a different machine so you don't confuse drivepool (and then Remove the old drive from the pool after you've disconnected the old drive).
If you're adding the new drive to the pool then manually copying/moving the content from the old poolpart folder to the new one, you'll want to stop the drivepool service or at least turn off balancing/placement while you're doing that (and then Remove the old drive from the pool after you've disconnected the old drive).
If you're just Adding the new drive to the pool then Removing the old drive from the pool, letting DrivePool handle moving everything (perhaps with the option to handle damaged drives ticked), then you don't need to stop the service, though this is slower than the above methods (unless the old drive had Duplication enabled in which case you can use the option to re-duplicate later which makes it much faster at the cost of temporarily lowering your duplication).

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.