Shane

Hmm. I vaguely recall this has come up before. Basically the "total" (unduplicated + duplicated + free remaining) in DrivePool's gui is based on the file sizes rather than the size they take up on the disk, which aren't necessarily the same due to the way NTFS works. DrivePool is still (as you can see from the top left of the tooltip) aware of the actual size of the physical drive. Aha, found it: TLDR the DrivePool uses "file size" rather than "size on disk" for some of its calculations, and this is reflected in the GUI. If you want DrivePool to recalculate these just in case, you can use the GUI's "Manage Pool" -> "Re-measure..."

If I had make a wild guess, it's possible that the Windows 7 Backup is assuming the destination is a physical drive and attempting to use VSS or special NTFS metadata operations which aren't supported by DrivePool. For whatever it's worth, I'm using Veeam for my own system image backups and haven't encountered that issue.

gtaus is correct: if chkdsk unmounts the drive, Drivepool will notice the drive is missing and change the pool to read-only until the drive is remounted at which point the drive will merge back into the pool and the pool will become writeable again it is unlikely but if chkdsk goes wrong and effectively formats the drive, the pool will need to be told that the drive is permanently gone and whatever was only on that drive will be lost it is also unlikely but if chkdsk goes wrong and mangles the drive contents but the poolpart folder itself is intact enough for drivepool to recognise it, drivepool will attempt to merge it back into the pool which may result in conflicts Protips: use Windows Disk Management to take one of the pool's other good drives offline first, that way your pool will stay read-only until you put the good drive back online and you can thus check the suspect drive for yourself whether chkdsk did its job properly before you toggle the good drive back online to make the pool writable again if you don't already have backups, you can also take advantage of this read-only state to backup the current contents of the hidden poolpart folder on the suspect drive to somewhere else before running the chkdsk

I'd recommend adding the new drives or creating a new pool with them, and then moving the contents inside each old poolpart to the new poolpart - minus any system folders - rather than attempting to moving the poolparts themselves. Trying the latter may result in Windows complaining about the hidden system folder ("System Volume Information") that Windows creates within the poolpart folder. Alternatively, if you've got any spare USB ports, you could use USB drive dock(s) to help perform the migration? Preferably USB3, because USB2 would take a lot longer. Especially, don't try to cut and paste poolpart folders on a machine that has DrivePool installed. I just tested that to see what would happen, and ended up having to delete and recreate the physical drive partitions to get DrivePool to recognise them again.

The OS writes files by going (approximately) "create/open entry for file on drive's index, stream data to file from program, write details (e.g. blocks used so far) to drive's index, repeat previous two steps until program says it's done or the program says it's encountered an error or the drive runs out of room or insert-other-condition-here, write final details in the index and close entry for file". Or in even simpler terms: at the system level all files are written one block at a time, no matter how many blocks they'll eventually involve. Now a workaround for programs that deal with fixed file sizes is to ask the OS in advance "how much free space is on drive X" so that they can know whether there's going to be room before they start writing (well, "know" as in "guess" because other programs might also write to the drive and then it becomes a competition). But the catch there is that when the OS in turn asks the drive pool "how much free space do you have", DrivePool reports its total free space rather than the free space of any particular physical drive making up the pool. This is because it can't know why it's being asked how much free space it has (DP: "am I being asked because a user wants to know or because a program wants to write one big file or because a program wants to write multiple small files or because some other reason, and oh also if I've got any placement rules those might affect my answer too?" OS: "I don't know").

I haven't tested whether it will rebalance in that way; hopefully it doesn't, as that would cause the same sort of problem as above, but if it does there is the option to set OFP to only place new files and leave existing files where they are.

Ah, I see. Ordered File Placement overrides the normal "write new files to the disk with the most free space" rule. You've got Ordered File Placement set to "fill each drive until there is only 1% or 5 GB free on it" and you've still got 5.25 GB free on the first disk (and 5.44 GB on the next). So it's going to try to write files to the first disk until it's got less than 5 GB free. And since the file you're trying to write is 100 GB, it can't fit so DrivePool can't hit the limit that will let it switch to the next drive (which in this case wouln't be able to fit it either). Note that due to the way Windows (or any OS that allows files of pre-undefined size to be written) works, DrivePool can't know the size of any file before it's first (fully) written to the pool. First option: if you know the incoming files will always be 100 GB in size then set the plugin's "Or this much free space" to be 101 GB (or whatever figure will end up such that DrivePool can fill the disk past the limit without running out of space on that disk altogether. Second option: trying the SSD Optimizer plugin instead? It also supports ordered placement, so you could assign a fast disk that has enough space as an "SSD" to act as a buffer; set a very high fill limit on the SSD and archive drives in the plugin but then set the Automatic balancing trigger size (in the Settings tab) to be low enough, and either un-tick the "Not more often than every" option or make the time period low enough, that it can prevent the SSD from filling up. That way DrivePool can see the size of the file in the SSD and thus be able to figure out whether it's got room on the first (archive) drive or needs to try the next (and so on). So it (should) go: program -> writing files into "SSD" disk -> DrivePool can now see the finished sizes of each file and move them into the "archive" disks in order without getting stuck. Just make sure the "SSD" is fast enough that it can handle being the buffer.

Can you post your Settings tab?

You have to tick "Balancing plug-ins respect file placement rules" and un-tick "Unless a drive is being emptied" in the "File placement settings" category on the "General" tab of the Balancing settings.

It would run out of space before it could finish, and the program would get an error. However, normally the automatic balancing defaults include the Prevent Drive Overfill balancer being set to detect any drive with less than 100 GB free and emptying it into other drives until there is at least 200 GB free. So that situation is unlikely to happen unless you've changed the relevant defaults or you don't have enough space left on every drive in the pool.

If you haven't already, I'd start with turning off automatic balancing and copying each drive to a backup.

That's disturbing. Do you have a separate backup? Can you contact Stablebit and ask them to investigate?

Hmm. I suspect the folder is still actually named PoolPart.guid at the system level but there is now a hidden system file named desktop.ini inside the folder that is telling Windows Explorer to show the name as Contacts instead (because that's a thing in Windows). These hidden system files can sometimes accidentally get brought along with visible files during moves or copies by users (because Windows). If that's the case, deleting or renaming that file should fix the problem (I suggest doing this at the pool drive level rather than the physical drive level). You might need to go into Windows Explorer's View menu -> Options -> View tab and temporaily select "Show hidden files" and untick "Hide protected operating system files" for it to be visible to you.

It seems good at first glance, though I'm not sure about the scheduled task part. How would you do that? Direct movement between the poolparts, or using File Placement to tell LargePool that any file the task moves to an 'Old' folder is to be balanced into the CloudPool half of the LargePool?

In order: Pools become read-only while a drive is missing (or if a trial version expires) until that drive is returned or formally removed. This may be a problem for your plan (see bullet point four). Drivepool never splits files. It may split folders. If you try to remove a drive from the pool via the GUI, it will attempt to first move the files on that drive to a different drive (if any) in the pool. If duplication is turned on, duplicated folders will be read-only for the duration. If you remove a drive from the pool any other way, the pool becomes read-only until this is resolved. If a files are being copied to the pool when this happens, the result will depend on the copy method (e.g. a standard Windows Explorer copy window will request permission to continue and will only be able to do so once the pool is writable again). DrivePool uses standard Windows NTFS format (or ReFS if you want) so removed drives can be read by any matching Windows system. Based on my testing, "dpcmd ignore-poolpart" does not wait for open file handles to be closed. The results are as per bullet point four above. Renaming a poolpart will also 'disconnect' that drive (volume) from the pool, but poolparts cannot be renamed if they contain open file handles, so this may be a partial workaround (partial, because the pool will still become read-only until you formally remove the 'missing' drive via the GUI (or via dpcmd). Can you pause the copying at all? Alternatively, can you at least throttle the copying speed from the source? Then you could have the source filling the pool while you empty the pool to destination drives that you swap out as the latter fill (i.e. the drives in the pool act as a buffer so the source never needs to stop copying, so long as you can empty the pool faster than the source can fill it)? Edit: A third option might be to make a feature request for StableBit to add an advanced setting (advanced because it would be a 'use at own risk' setting) to DrivePool that enables forcing pools to remain writable even when a drive is missing. I don't know how feasible that would be.