CyberSimian

I completed emptying the pool, and then deactivated the licence, uninstalled Drivepool, and rebooted. All disks had worked OK during the file copying (which took several days, with the PC on continuously), but the first time that the system woke from hibernation subsequently, one of the disks was missing again! So the problem was clearly not caused by Drivepool. While trying to diagnose the cause of the problem, I had changed USB disks, changed USB cables, and changed USB sockets, none of which cured the problem. It then dawned on me that the one element that I had not changed was the USB power supply. The disks that failed had all used the same USB power supply. I have now replaced that power supply with a spare one, and I am pleased to report that so far the problem seems solved. I have measured the USB power supply voltage using a multimeter, and it reads 12.3 volts, which seems reasonable. But of course this was effectively open circuit, and I suspect that when loaded, the voltage would drop to the point where it is unable to spin up the disk, resulting in the "missing disk" condition. The erratic symptoms experienced by the original poster seem similar to mine, so I would suggest that he checks the power supply, and replaces it with another if he has a spare one. A point to remember is that a hard disk requires significantly more power during spin-up than it does during steady-state operation. A few years ago I checked the specs of the disks that I had at that time. Steady-state operation required around 5 watts for slower disks, increasing to 8-10 watts for faster disks. But during spin-up, the disks required 25-30 watts (but only for a second or two). If the power supply cannot provide 30 watts simultaneously to each of the disks connected to it, spin-up failures may occur. -- from CyberSimian in the UK

I have been experiencing a similar problem with my four USB-disk drive pool. On wake from hibernation, Drivepool would detect a missing disk, and the Windows event log contained "The driver detected a controller error". This did not happen every time, but it was sufficiently frequent to be annoying. Assuming the USB disk was developing a fault, I replaced it (and the USB cable) with a different disk, but the error still occurred, and what is more it occurred on the replacement disk(!). I then unplugged the USB disks from the motherboard sockets, and plugged them all into a USB hub, and the error still occurred. The drive pool concept is great, but I don't know anything about the complexities of implementing it on Windows. My simple-minded assessment of the Drivepool product is that it is too fussy, and diagnoses errors when there are none. I am currently in the process of copying all of the files in the pool to non-pooled areas of the disks, and will be uninstalling Drivepool when that is complete. If I then still get errors, I will know that Drivepool was not to blame. -- from CyberSimian in the UK

On the few occasions when I have wanted to re-arrange the contents of the pool, I have used the Windows "Services" panel to stop the Drivepool service. In fact there are two Drivepool services that run continuously: Drivepool service Drivepool shutdown service I stop both services before changing pool content, but I don't know whether it is necessary to stop both. However, I also don't know what state the service is left in, so I don't risk restarting the Drivepool services from the "Serivces" panel. Instead I reboot the system. It would be useful if someone who actually knew the details could post the relevant information... -- from CyberSimian in the UK

If file A is copied to file B, the timestamps for B show: "Date created" shows the date that file B was created. "Date accessed" shows the date that file A was most-recently accessed. Since it had to be accessed in order to copy the file, this date is the same as "date created" for file B. "Date updated" shows the date that file A was most-recently modified. This leads to the apparently contradictory situation where file B appears to have been modified before it was created. I would suggest that you perform some simple file-copy tests with small files to see how the various timestamps behave. Then you will know for sure what to expect when file balancing occurs. (I have never rebalanced my drive pool as I cannot see the point of doing so; if I add an empty disk, all new file copies to the pool go to the new drive until such time as it is approaching the same occupancy as the other drives.) -- from CyberSimian in the UK

The NTFS file system retains three different timestamps: date/time file was created date/time file was last accessed (e.g. read) date/time file was last updated (i.e. written) You can use the DIR command to view these different timestamps. Use "dir /?" to see the built-in help. -- from CyberSimian in the UK

This sounds similar to the "/R" option of CHKDSK: /R Locates bad sectors and recovers readable information (implies /F, when /scan not specified). I used /R once on a disk that was not large by today's standards, but it still took days to complete. Presumably it reads and writes every sector on the disk, but without destroying the existing data on the disk. I see from the built-in help for CHKDSK that there are more options in Windows 10 compared to Windows 7. -- from CyberSimian in the UK

Instead of assigning drive letters to your 20 USB disks, you could mount them in a folder. This means that the disks can be accessed individually at any time to catalogue or check their content, but they don't clutter up Windows File Explorer (since they appear as subfolders of the C: drive). You can also CHKDSK the individual disks if needed. I have set up my drive pool in this way, although I have only 4 USB disks in the pool: C:\Mount\Pool_1 C:\Mount\Pool_2 C:\Mount\Pool_3 C:\Mount\Pool_4 You specify the mount point on the Windows panel where you assign drive letters. -- from CyberSimian in the UK

Do you have Windows "fast start" enabled? Remember that "fast start" is simply hibernation by another name. When you select "Shutdown", your system actually hibernates. "Fast start" is enabled by default when you first install Windows, and if you disable it, major Windows updates will re-enable it (so you need to disable it again). "Fast start" is enabled and disabled in Windows power settings. I use hibernation on my own system, and I have measured the power consumption at around 3 watts when the system is hibernating. Interestingly, it is also around 3 watts when the system is shutdown, so I understand your desire to disconnect the power from the system. However, remote-control electric mains sockets and timers also consume around 3 watts. Only a manual on/off mains switch will truly eliminate electricity consumption when the system is not in use. I don't use the cloud, so I don't know how that affects things. -- from CyberSimian in the UK

When I purchased the Drivepool licence, I chose not to purchase a Scanner licence as well, so that may be the difference between your system and mine. I am a novice at using Drivepool, so I regret that I don't have any other ideas as to the cause of the problem. -- from CyberSimian in the UK

That had not occurred to me. I suppose that the trial version of the software is linked to the PC on which it is installed, and not to the user who installs it. (I used the trial version on the old PC before deciding to purchase a licence, so if the trial version can be installed only once per user, I am out of luck.) -- from CyberSimian in the UK

Thank you for the suggestion, but copying the data is not the problem -- a simple XCOPY will do this. If "P:" is the drive pool on the old PC, and "N:" is the drive pool on the new PC, then the following command will copy the contents of the pool: xcopy p:\*.* n:\*.* /h /y /k /s /e /r /v with appropriate values for the /EXCLUDE option to exclude folders such as "System Volume Information" and the various recycle bins. But this requires two Drivepool licences. I think that ROBOCOPY and RSYNC would also require two Drivepool licences. -- from CyberSimian in the UK

I don't know whether this change was intentional (I am still running 2.2.5.1237), but there is a simple way that you can bypass the UAC control. This method works for any program: (1) Create a task in "Task Scheduler" that starts the Drivepool GUI and which runs with maximum privileges. (2) Create a desktop shortcut that runs the task created in (1). When you click this shortcut, the task will run, and because it has maximum privileges, the UAC prompt will not appear. Details are in the attached ZIP file. -- from CyberSimian in the UK shortcuts_without_uac.zip

I am in a similar situation. I have built a new PC, but none of the disks in the old PC will be used in the new PC. I therefore need to transfer all of the files in the drive pool in the old PC to the drive pool in the new PC. This requires TWO Drivepool licences, since I need to have Drivepool installed on both systems concurrently for the duration of the transfer. If I were going to continue to need a drive pool in the old PC, I would purchase another licence. But I don't have that need at present. The only way that I can think of to transfer the files is to: (1) Transfer the licence to the new PC. (2) Remove the disks from the old PC, and connect them temporarily to the new PC. This supposes that you have enough SATA or USB sockets available on the new PC. Drivepool should recognise the old drive pool on the old disks when they are connected to the new PC. (I have not tried this yet.) (3) Create a second drive pool in the new PC, using only the new disks in the new PC. (4) Move the files from the old drive pool to the new drive pool. Drivepool will automatically distribute the files over the disks in the new drive pool. (5) When complete, the old drive pool should be empty, so delete that pool, disconnect the disks, and re-install them in the old PC. -- from CyberSimian in the UK

This change worked for me. I don't know the specific reason that it did not work for you, but I would suggest trying: (1) Stop the Drivepool service. (2) Make the change to the file (using an "Administrator Command Prompt" if necessary). (3) Reboot without restarting the Drivepool service. I used this setting for several months before deciding to revert it, for the following reasons: (1) I use Drivepool on an HTPC, and it was quite annoying to browse to a folder in the pool, and then have to wait while the disk spun up before being able to view the media on that disk. (2) With the two external USB disks in the pool, I would occasionally find that one of them had disappeared from the pool. I powered off the HTPC, unplugged the USB disks, and CHKDSK-ed them on a different system, but this never detected any errors. My suspicion is that one of the USB disks took slightly too long to spin up when accessed, and Drivepool concluded that the disk was missing. Another way to view this is to say that Drivepool does not wait long enough for a disk to spin up. Since reverting to the original setting, I have not had any occurrences of Drivepool diagnosing a missing disk. -- from CyberSimian in the UK

Thank you for posting this. I have been using Drivepool for two months now, with one internal SATA disk and two external USB disks in the pool. I too noticed that the USB disks seemed to be accessed continually. They are Western Digital "My Book" disks, and the disk LED: Flashes rapidly when the disk is being accessed. Remains constant when the disk is spinning but not being accessed. Flashes slowly when the disk is spun down. I noticed that the two USB disks were accessed briefly in unison every 3.5 seconds. After making the change that you suggested and then rebooting (need to "Run as Administrator" to make the change), I am pleased to report that the disks are now no longer accessed every 3.5 seconds -- the LEDs remain constant, or flash slowly. In my experience USB disks don't obey the Windows "spin down" time in the power plan -- the USB disk controller decides for itself when to spin down the disk. My suggestion: if Drivepool can determine that Bitlocker is not in use, Drivepool shouId automatically use the setting that you suggested. If Drivepool cannot determine that Bitlocker is in use, the setting should be made available on the Drivepool "Settings" menu. -- from CyberSimian in the UK