Shane

TLDR is stick to the GUI unless you have an urgent reason to do it manually. DrivePool 2.x expects every poolpart to have a unique UID (the dashed alphanumeric string after the dot in the hidden PoolPart.* folder name) so you'd have to: either pull the old drive and clone the entire volume to the new drive on a different machine before putting the new drive into the drivepool machine and wiping the old drive's poolpart before putting the old drive back in or turn off any automatic and immediate/forced balancing, add the new drive to the pool first, stop the service, use robocopy (making sure to include directory timestamps) as an administrator to copy the content - excluding .covefs and any protected system folders - within the old poolpart to the new poolpart, and then start the service, remove the old drive, turn on balancing (if desired) and do a re-measure (and maybe a duplication check if you're using that). Basically there's good reasons to use the DrivePool GUI to add new drives and then remove old drives. It's slower but can be as simple as just using the GUI to add the two new drives and then remove the two old drives (you can queue multiple drives) and then let DP take care of everything inbetween - which has much less chance of something going wrong and you can keep using the pool in the meantime; this can be particularly handy if the pool is being shared on a network with other people. (Incidentally, I have tested copying a poolpart folder itself on a machine that had two pools, and the result after I ejected the old drive and rebooted was the new drive showing up... as part of the wrong pool - so I really don't recommend trying that).

Yes, that's the pool drive letter. So if the hidden poolpart folder in the root of your bad drive is named "PoolPart.654e1b5c-05b8-44a2-8b6b-a0251f2ec7d6" then the command you would use to tag that particular poolpart to be ignored would be: dpcmd ignore-poolpart n: PoolPart.654e1b5c-05b8-44a2-8b6b-a0251f2ec7d6

In the DrivePool GUI, at the very top where it lists your pool(s) - NOT the Disks section below that - what is the string inside the first set of parentheses? E.g. on mine: "DrivePool (P:\) - (39.1 TB)"

Hmm. Just checking, you are using the pool's drive letter and not the bad drive's letter, confirm? If the pool itself is mounted as a path (e.g. "c:\mounts\poolP") instead of a drive letter (e.g. "p:"), try the path. If it's not mounted as either a path or a letter, try mounting it as either first and use whatever you've assigned.

Try the following command from a command prompt run as an administrator where pooldriveletter is the drive letter of the pool itself and poolpartname is the hidden folder beginning with "PoolPart." on the bad drive: dpcmd ignore-poolpart pooldriveletter: poolpartname This should tag the relevant poolpart to be ignored by DrivePool at the system level, which will effectively make it "missing" as far as the pool is concerned; the pool will become read-only until this is reversed or the "missing" drive is removed from the pool - which you should be able to immediately do as DrivePool should treat it just like removing any actually-missing drive and drop it without attempting to retrieve anything from it.

Updating shouldn't make things worse but if the drive's at the point where it's generating BSODs then I doubt updating would make things any better either. Personally I'd physically remove the drive from the server altogether (it'd then show up as a "missing" drive in DrivePool and can be safely removed from there); if I still needed to (try to) get any remaining data off the bad drive I'd use a separate test machine so any further BSODs wouldn't interfere with the server.

Based on my own experiences, neither. Likely it means the drive's own firmware found something wrong (thus the S.M.A.R.T. flag) and then dealt with the problem itself, it's just that Scanner noticed the warning inbetween detection and resolution. You might find further info in the logs (C:\ProgramData\StableBit Scanner\Service\Logs), or if you enable Scanner's email notifications and it happens again the email would mention which particular S.M.A.R.T. warning/error occurred. As I use both duplication and nightly backups I'd just double-check that those are on and wouldn't worry about it; I'd only consider replacing the drive if the issue kept happening (more) often or became a permanent error rather than a temporary warning. YMMV.

Short answer is basically yes to both: the basic concept of presenting multiple physical drives as a single virtual drive is the same but the implementation under the hood is different, so you technically can manually remove the empty directories if you have to for some reason. If you have run into a situation where it's actually necessary (e.g. perhaps an issue involving programs that need to access the poolpart drives directly instead of via the pool drive and don't like empty directories for whatever reason) to remove the "empty" folders, keep in mind: if you remove them from all of the poolpart drives in which they appear you will be removing them from the pool as if you had deleted them from the pool drive (i.e. if you are using some kind of automated tool to remove empty folders from a poolpart drive, you will have to account for whether the tool is able to check the other poolpart drives to see whether a folder is empty or "empty"). if you are using duplication then drivepool may recreate "empty" folders as necessary to meet the designated duplication level on its next consistency check. if files in a folder are later added/moved to a poolpart drive on which the relevant folder(s) don't exist anymore then it will incur the overhead of having to recreate the folder(s) before adding the files. it would be a good idea to tell drivepool to remeasure the pool afterwards (from the GUI, Manage Pool -> Re-measure...). TLDR don't do it unless it's necessary. Hope that helps.

Hi digimon, please use the contact form to get directly in touch with StableBit; under "What do you want to contact us about?" choose "An issue with licensing".

Hmm. It may still be seeing the "deleted" files in the Windows recycle bin? Try deleting the hidden system $RECYCLE.BIN folder from the pool drive and then do another reboot and re-measure. ( e.g. via command prompt run as administrator, rd /s /q k:\$recycle.bin ) You might also want to check if Windows has decided to stick any $recycle.bin folders in strange places (e.g. I recently found one in my pictures folder) and delete those too. If that doesn't help, I'd recommend asking for support via the https://stablebit.com/contact form.

DrivePool keeps service logs in the C:\ProgramData\StableBit DrivePool\Service\Logs\Service folder which may be of help in tracking down why you're still getting the errors? You could also try using dpcmd check-pool-fileparts from a command prompt run as an administrator; it will give usage examples. e.g. dpcmd check-pool-fileparts p:\ > %userprofile%\desktop\cpf.log would perform a full consistency check of the pool p:\ and save the results (showing directory status and any file inconsistencies) to a cfp.log file on the current user's desktop. Note that this can take a long time if you have a big pool.

That's quite a weird one but so long as the free space is remaining the same thing I'd think it harmless. You might want to file a bug report anyway?

That's weird. Did you turn off the SSD Optimizer altogether or does it have Ordered Placement turned on (if the latter, try turning it off)? Do you have any File Placement rules set? What other balancers do you have active?

Note that it isn't possible to have DrivePool choose the destination drive(s) based on the size of the incoming file, as the latter isn't something it can obtain in advance due to the way Windows file operations work. At best, you could request a feature to have DrivePool optionally report its free space to Windows based on the current destination drive rather than that of the free space of the pool as a whole (although I'm not sure whether the balancers would be able to override that as-is). Pro: for copying single files where Windows/applications check the file's size versus the destination drive free space you would know in advance whether the transfer was completable. Con: for copying multiple files where Windows/applications instead check the aggregated size versus the free space they could refuse to perform the transfer even though there'd be enough room on the pool (e.g. copying a hundred 10GB files as one Explorer operation to an empty 10TB pool with a 500GB buffer drive could be rejected due to "insufficient" space on the buffer drive even though DrivePool would be able to handle the operation).

Your suspicion is correct; if you've told DrivePool via the SSD Optimizer to use particular drive(s) as a buffer for new files then new files are going to be limited by the free space of those drive(s). Note also that the "Fill SSD drives up to X%" option only causes a new file to bypass the buffer if the drives marked as SSD are already X% full before copying the new file.

There would be some extra wear, but honestly I think not much. Maybe vaguely comparable to doing a chkdsk of every drive (without checking for bad sectors)? If you're using enterprise/NAS drives I would expect it to be a drop in a bucket kind of situation. Since hotswap!.exe appears to work to eject your drives but DP still does a re-measure, I'd suggest enabling CoveFs_IsDiskRemovable and then adding the DISKPART script to see if that works, e.g.: DrivePool_RunningFile check to ensure nothing is running stop the stablebit drivepool service to ensure nothing begins running DISKPART script to offline the relevant pool drive (log the errorlevel - if it's reliably zero and stable, keep using it) hotswap!.exe to eject the relevant poolpart drives restart the stablebit drivepool service

I'd suggest contacting Stablebit support with a copy of your error logs as described in this article.

File Placement operates at a real-time level below that which would allow seeing the size of files, but if you're using CloudDrive then as I understood it (normally) its chunking system should automatically take care of the problem you're worried about as CloudDrive drives normally exist on the remote cloud storage service as a series of small files (chunks). So for example if you had a 50GB CloudDrive drive that was created using 10MB chunks it would normally exist on the cloud storage as a collection of up to (approximately) fifty thousand chunks (files), and if you copied a 10GB file to it, that 10GB file should be broken up into one thousand 10MB chunks to be uploaded to the cloud service (again, this is approximate). If you hover the mouse cursor over an existing CloudDrive drive's size in the CloudDrive it should show a tooltip indicating the drive's chunk size. Have you run into problems uploading files larger than 5GB via the CloudDrive? Incidentally I believe that the Balancer plugin system might be capable of doing what you wanted for existing files (i.e. see the size of files that are already in the pool and move them accordingly) but someone would have to code a new Balancer plugin to make use of that.

Windows obtains the removability status from the hardware, so I'd suggest checking the documentation for the HBA to see if there's a internal setting or manufacturer utility to mark the drives/buses as hot-pluggable. (There did indeed used to be such a key and yeah Microsoft removed it for their ineffable reasons.) You might also try this piece of software http://mt-naka.com/hotswap/index_enu.htm as it does have command line functionality - but it may not support your hardware. Also, disclaimer, I haven't tried it myself; proceed with caution.

Did some looking. AFAICT there's no official DP method (command-line or GUI) to gracefully offline a pool. Tagging @Christopher (Drashna) ? What I have so far found seems to work, with a bit of experimentation today, was the following: 1. Ensure that all relevant poolpart volumes appear to Windows as ejectable drives, then set the override for CoveFs_IsDiskRemovable to true and restart Windows; the pool drive composed from those volumes should now itself show up as an ejectable drive (but doing so via the Windows GUI will just have DrivePool immediately redetect and remount the pool). 2. In your batch file the command diskpart /s scriptfile.txt should now* be usable to take the pool offline where scriptfile.txt is the name of the file containing the following text (replacing pooldriveletter with the letter of your pool drive): SELECT VOLUME pooldriveletter OFFLINE VOLUME 3. If the command was successful then the errorlevel for the diskpart command should be zero (if you need to check for that in your script) and the designated pool should gracefully disappear from DrivePool; you should then be able to eject / depower the relevant physical drives. I might still recommend using DrivePool_RunningFile to ensure that DrivePool isn't in the middle of any maintenance operations, as I don't know if interrupting those in this manner would cause DrivePool to want to recheck the pool, but if you find it doesn't then I guess it won't be needed! How are you scripting the JBODs to power on/off? *I found that using diskpart to offline a non-removable pool drive would sometimes crash diskpart/drivepool/windows so I don't recommend trying that.

Glad to hear it went smooth. Are you using duplication instead of backups? Won't help with accidentally deleting a file but at least if a drive karks it that should keep you going. No plans to visit Tassie any time soon sorry, I'm stuck in Queensland at present. I'll just have to raise a glass in your direction I guess. The green on black does bring back memories of my uni days with the old vax/vms terminals!

Scanner does monitor (e.g. every minute or so, can be configured) SMART data and also regularly (e.g. monthly, depends on your setup choices) scans both the file system and every sector on your drives to check that they are readable, and can attempt repairs. The scanning as a (nice) side-effect can also prevent some bit rot, as the act of scanning ensures the drive will be regularly fully powered up and that the drive's own detection/correction features will (or at least should) automatically examine/repair/reallocate cells/sectors in the background as Scanner reads them. Note that SSDs are much more susceptible to charge decay than HDDs, as the former relies on a much faster but less stable storage method; it can vary widely by the type of SSD but the general takeaway is that a SSD/HDD that's been sitting unused for X months/years respectively might not keep your data intact (the bigger the X, the smaller the trust). Anyway, aside from the problem mentioned with SSDs above, drive-based bit rot (as opposed to other sources and causes, e.g. due to bad RAM, EM spikes, faulty controllers, using non-ECC memory in a system that doesn't get cold-booted regularly, etc) is by itself quite rare, but it is yet another reason to keep backups. TLDRs: if you keep necessary data on a SSD, I suggest keeping it powered continuously or at least regularly. Regularly scan your SSDs and HDDs. Keep backups. If you're not using an ECC setup, consider disabling "Fast Start" in Windows 10/11 and restarting your PC occasionally (e.g. once a month) if you're not already doing so.

Step 1: Right-click D:\DRIVEPOOL and choose Properties. If it reports 0 files and 0 folders then proceed to step 2, else halt. Step 2: Without stopping the DrivePool service, rename the D:\DRIVEPOOL folder to something else (e.g. D:\OLDPOOL). If nothing complains or breaks then proceed to delete the renamed folder, else halt. Trip was good, but these old bones are feeling the miles afterwards. That green is very garish on a white background btw. P.S. You mentioned "If I did the wrong thing, there goes decades worth of stuff" - next step might be to plan/organise backing up your pool?

Default pool behaviour is to use whichever drive has the most free space at the time; your "Lightroom" volume has the least free space so unless you change the default behaviour it will be used only after all of the others have enough files placed on them that they all have less free space remaining than it.

DrivePool returning RAW for pools to chkdsk is normal behaviour (because a pool is not itself a physical drive with sectors to check, even if it's made up from them). It may just be that your guess of another application grabbing the directory at the time is correct, and that xcopy and powershell copy just have better handling of such situations (which I can believe).