Leaderboard

It won't affect unduplicated mode. It's just there's currently a bug that may cause duplicated files to be read incorrectly if read striping is enabled - so disabling it now means no risk from the bug if you happen to turn on duplication in the future.

Far as I can tell it's a normal situation, the pool's working properly.

Hi DMZH, it's likely the result of it being so much bigger than all the other disks interacting with the default balancers (most likely the Duplication Space Optimizer) and DrivePool's preference to otherwise write to the fastest disk with the most free space. If you're not using duplication and/or want an even distribution of used space, you could turn off that balancer and turn on the Disk Space Equalizer balancer (set it to equalize by space used). You may need to adjust DSE balancer's priority (e.g. if you are using Scanner, make sure it is lower than Scanner).

I don't really need those tools because I also setup a drive hosted on my home server via SMB using StableBit CloudDrive, and that drive is now part of the M:SATA pool for lazy (not real-time) duplication of files that are hosted on the SATA disk. That means I have a current copy of all my pool's files on a different computer. I also run a nightly backup of the directories hosted on the N: pool as a historical backup, which is accomplished with Duplicati and stored off-site. I've come across no issues with Duplicati and DrivePool so far. The resulting backups can be restored without problems.

Great to hear. However, be aware that currently FileID does not behave as expected on pools, so software that assumes FileID is perfect may break badly after a reboot. Link. Currently there is no ETA on a fix from StableBit. In summary, generally a FileID is presumed by apps that use it to be unique and persistent on a given volume that reports itself as NTFS (collisions are actually possible albeit astronomically unlikely), however DrivePool's implementation is such that collisions after a reboot are effectively guaranteed on a given pool. Affected software is that which decides that historical file A (pre-reboot) is current file B (post-reboot) because they have the same FileID and proceeds to read or write the wrong file. TLDR, if you're not using such apps (so far some backup/sync tools, e.g. OneDrive, some have also reported FreeFileSync) you're unaffected, if you are then you should be careful not to use them with anything you keep on a pool.

That worked perfectly. I chose a variant of the first option you suggested: - a 4x 2TB NVME pool at L: with... > Duplication Space Optimizer plugin enabled, > Disk Space Equalizer plugin enabled, > duplication enabled, > real-time duplication disabled, > read striping enabled - a 1x 4TB SATA pool at M: with... > Disk Space Equalizer plugin enabled (for when I add disks to this pool in the future), > duplication disabled, > read-striping enabled (for when I add disks to this pool in the future) - a pool at N: made up of pools L: and M: with... > the Ordered File Placement plugin enabled prioritizing the L:NVME pool for writing new files, > duplication enabled, > real-time duplication disabled, > read-striping disabled (I don't want to include slow M:SATA disks in a read stripe) With these settings: - sequential writing to pool N: happens as fast as the max speed of one NVME disk (7000+ MBps) - sequential reading for unduplicated files happens as fast as the max speed of one NVME disk (+/- 7000 MBps) - sequential reading for duplicated files happens almost twice as fast as the max speed of one NVME disk (12,000+ MBps) - my usable NVME pool capacity is 3.65TB (half of 7.3TB formatted) - all files are hosted and duplicated on the L:NVME pool - a 3rd copy of all files exists on the M:SATA pool - everything can be expanded or repaired at a later date by adding or replacing disks as needed - this all happens seamlessly through a single partition at N: I'm particularly impressed that the M:SATA pool is intelligently only keeping 1 copy of every unique file from the L:NVME pool, and not duplicating duplicates. It just lists the duplicated files on L: as "Other". I'm using this pool to host all my Windows User directory's libraries (Documents, Pictures, Videos, Music, etc, with the sole exception of AppData). So far, this is almost as good as ZFS in some ways, and better in other ways. It blows Intel RST, Microsoft Storage Spaces, or Windows Disk Management arrays right out of the water. I'm annoyed I haven't discovered DrivePool sooner.

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

Hi Mesonto, it's not possible within a single pool. If the requirement is just to avoid having to change shares on the LAN you could consider using nested pools (e.g. E and F supporting D)? Issues to consider would be 1, as the drives are already in use for D it would involve either a lot of background time adding/removing drives or some delicate manual work migrating/reseeding the pool structures, and 2, if you have any exceedingly deep path lengths (over 32 thousand characters!) in your existing pool you may not be able to nest it.

Unfortunately, no, not currently. The Windows apps (including XBOX apps) do some weird stuff that isn't supported on the pool. And adding support for it isn't trivial (it's likely some very low level file system implementation that may be very difficult to implement). That said, you *could* use StableBit CloudDrive and the local disk provider to create a drive on the pool, and install the games to that. Because it's emulated at the block level rather than the file system level (like StableBit DrivePool), it shouldn't have the issues with the Windows/XBOX Apps

Three years ago I tried using DrivePool with a set of five Western Digital "My Book" USB drives. The problem was that one of them kept dropping out of the pool. And yet, when unplugged, replugged, and CHKDSKed, no problem was ever found. In the end I came to the conclusion that DrivePool was not waiting long enough for the disk to spin up, and so claimed that the disk was missing from the pool. I decided to uninstall DrivePool and manually distribute files over the five USB disks. This has produced no problems with slow spin up in the three years that I have been doing this, so I don't think that it is a Windows problem (i.e. Windows is waiting long enough for the disk to spin up). I think that it is DrivePool not waiting long enough for the disk to respond (spin-up in the case of USB disks whose spin-down cannot be disabled by the the user or Windows). -- from CyberSimian in the UK