No, that wouldn't work. Since we store the actual files on each drive, there isn't a drive large enough in this situation to store the file.
The OS may see all the space available, but the driver for the pool is intelligent enough to know that no disk in that pool as enough space to store the file, and gives you an out of space error.
Specifically, when you go to create/copy the file, Windows normally queries for free space (to see if it will fit). The DrivePool driver gets that query, and then queries each individual disk (based on the "real time placement limits", if any), and looks at those values. If no disk has enough space to put the 4GB file (and in this example, no disk has the space), the driver returns the "not enough space" error. This is passed to the program querying, and causes the operation to error out with the appropriate error.
And if the entire pool was full? Then it would cause problems.
However, one of the balancers, "Prevent Drive Overfill" tries to keep all of the disks in the pool 10% free, or 100GBs free.
This can also cause issues when using the SSD Optimizer balancer, if you have very small cache/SSD drives.
Also, you could use the Ordered File Placement Balancer to minimize this possibility, as it fills one (or two, with duplication) drives at a time.
If we used a block based solution (such as how StableBit CloudDrive, RAID or Storage Spaces works), then yes, that would work fine. But you're storing the blocks of RAW data, so it's not easily accessible without ALL of the blocks, and those would be divvied up between the different disks.
