Shane

The options should do as they say; I would suspect that the Disk Space Equalizer isn't fully compatible with the SSD Optimizer, and/or another balancer or file placement rule that you might have active, or that maybe it doesn't handle well when a pool contains disks of widely disparate size?

It could be the NTFS permissions are borked. Try https://community.covecube.com/index.php?/topic/5810-ntfs-permissions-and-drivepool/ (first two posts) to see if reveals the missing hidden PoolPart.guidstring folder?

Short answer: there is no command that directly toggles a pool Read-Only. As a workaround, if you add a drive* to the pool and then use the Drive Usage Limiter to instruct DrivePool to never use it, you can use the dpcmd ignore-poolpart and dpcmd unignore-poolpart administrator commands to make that poolpart drive go temporarily "missing" which will result in the pool being read-only in the interim (without any files becoming unavailable, because none are on that poolpart). However note that this will also result in DrivePool remeasuring the pool afterwards. You may also be interested in the DrivePool_RunningFile setting (link) to help detect when DrivePool is performing any background tasks (e.g. remeasuring). *for example you could add a small USB thumb drive, or partition off a tiny volume from a larger drive

The transactional sync should mean DSynchronize doesn't need to scan the whole drive to find changed files, just rely on the USN journal notification, but I haven't personally tested it. Truly simultaneous writes to both drives would require some kind of virtual drive or share or RAID equivalent. You might want to look into a hardware-based RAID6 array or switching to a ZFS-based OS/DAS/NAS (e.g. TrueNAS, Unraid, QNAP, Synology etc) if you have a need for zero-downtime despite two concurrent drive failures (and if enough money is riding on it, also looking into high-availability clusters where you've got duplicate machines not just duplicate drives).

Hi Saaiberke, You may need to re-enter your Balancing and/or File Placement settings, so I suggest taking note of them first. If you are using your boot drive as part of a pool, you should remove the boot drive from that pool for the migration. (Anything else on the boot drive that you want to keep should be copied to another drive.) You should deactivate your StableBit license(s) on the WHS2011 install as a final step before replacing it, so that you can reactivate the license(s) on the Windows 10 install without having to contact StableBit to help. Note that while the DrivePool license is deactivated your pool(s) will be read-only. I recommend powering down your system to physically disconnect your pool drives before proceeding with the OS replacement, then powering down to physically reconnect the pool drives after you have installed DrivePool on the new OS. P.S. You should also ensure that Read Striping is disabled on your pool(s) when they come back, as there is currently a Read Striping bug that can cause the wrong data to be read from duplicated files in the pool.

Nothing I personally know that will bidirectionally sync (even near enough to) simultaneously AND expose the drives independently AND replicate hardlinks. I'm told SyncThing can be run as two instances on different ports for bidirectional local sync (I haven't done it myself) but I'm pretty sure it doesn't replicate hardlinks. ... After quite a bit of googling: Dimio DSynchronize might be what you're after, as it claims to support bidirectional sync, transactional sync and hardlinks? You've got me curious as to what needs both drives to be synced and independently simultaneously accessible when they're on the same machine.

Correct. Symbolic and junction links are supported for the pool drive, hard links are not supported (and cannot be created) for the pool drive. Linking directly into a poolpart folder (e.g. mklink /h d:\links\file1.txt d:\poolpart.guidx\file1.txt) is technically possible but not supported as any subsequent writes via that link will result in the poolpart no longer matching with any duplicate(s) on the other drive(s) in the pool (and DrivePool's nightly consistency check will then throw up an error about it along with an option to sync the newest version of the file). E.g. I use a set of junction links to my pool's poolparts so I can take advantage of USN journaling for rapid searches, but I never write via those junctions.

Ah, got it, I was confused by "having to unhide to read". It's not possible to avoid the hidden poolpart folders, DrivePool is built on them.

Hi Salim! Let's take an example where you have three physical drives, D and E and F. You create a pool P - a virtual drive - and you add D and E and F to this new pool. DrivePool handles this behind the scenes by creating a hidden "D:\PoolPart.GUID1" folder and a hidden "E:\PoolPart.GUID2" folder and a hidden "F:\PoolPart.GUID3" folder. Any file you then put in P is stored in a special hidden folder on D or E or F. Or if you have real-time duplication enabled it will store the file simultaneously in two (or more if you want) of those hidden folders. For example, "P:\mystuff\myfile.txt" might be stored in "D:\PoolPart.GUID1\mystuff\myfile.txt" and "F:\PoolPart.GUID3\mystuff\myfile.txt". As to which of the D, E and F drives it picks, the default is the drive(s) with the most free space at the time. It is easy to tell DrivePool to "only use these (two or more) drives to store duplicates" but getting it to "always make sure this one drive has a duplicate of what's on (two or more) other drives" is more complicated (you have to nest pools). You use the virtual pool drive to read and write files in the pool, and if duplication is enabled DrivePool will automatically try to read from the fastest drive that holds the files. You do not need to unhide anything; in fact normally you should never access the hidden PoolPart folders yourself, as DrivePool needs to manage those autonomously to work properly. (note: some versions of DrivePool start with Manage Pool -> Performance -> Read Striping ticked, however that feature is buggy and you should check and turn it OFF until a fix is released). Hope this helps!

Rebalancing tends to put additional load on any device (e.g. a USB enclosure) that handles multiple drives within a pool. If the device is (becoming) flaky then that load can cause one or more drives or even the entire device to drop. I'd suggest taking a look at the hardware you're using?

DrivePool will normally write any given file to the drive with the most free space; if you mark both as SSD in the SSD Optimizer, it should alternate writing files between the two as it detects each has less free space than the other - which should tend to maximise write speed if you're writing multiple files side-by-side.

In the course of Scanner finding and recovering the damaged file, the drive's firmware may have been able to repair the damaged sector rather than needing to reallocate it. Personally I would: Take note of the file that was damaged and manually check that the File Scan was actually able to completely recover it (e.g. open it and/or compare it to a backup or copy elsewhere). Force a new scan of that drive again to see if the drive is no longer damaged. If the new scan doesn't find more problems and SMART remains clear then I'd keep using the drive. If I haven't recently, make sure my backups are in working order.

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.

I've set up a very basic discord. Presuming I've ticked the right boxes, the link is: https://discord.gg/9TzrmrxvYz Please keep in mind that it's not any more official than any other end-user doing it (i.e. not at all). Any problems, please message me.

I've pinned this topic and have added a mod notice to the top, summarising the issue, at least until StableBit can release a fix.

I've pinned this topic and have added a mod notice to the top, summarising the issue and how to disable Read Striping, at least until StableBit can release a fix.

Based on the latest post here, I recommend disabling read-striping on all pools as a general precaution unless you can confirm your system is not affected by the hashing error.

P.S. I do strongly recommend making sure that Manage Pool -> Performance -> Read striping is NOT ticked.

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

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.

"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 Dalmus! Yes, pretty much what you're thinking: power down, replace the drive, power back up, tell DrivePool to remove the missing bad drive and to add the new good one, it will handle the rest. If you had any drive-specific rules (e.g. file placement) you would have to update those.

Moved thread to CloudDrive General. Glad to hear you were able to get it going, quite a strange error.

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.