Shane

Yeah, to keep both read and write you'd have to go with RAID 1 (software or hardware based) to mirror a pair of drives. If your choice of RAID doesn't come with its own remote notifications but still allows per-drive SMART (e.g. Windows Pro software raid) you may wish to use StableBit's Scanner software so that if either drive dies or starts going bad it can send an email, app notification or SMS to let you/whoever know.

Just delete the old folders and remove the letters. Don't format the drives. DrivePool stores a pool's files inside a hidden "PoolPart.UID" folder (where each UID is a unique, dashed alphanumeric string) in each drive that's part of the pool, so formatting any such drive would erase that drive's hidden folder and any data in it.

No idea, sorry. If you're happy with just using the All-In-One plugin then I'd say keep going with it, otherwise you could try lodging a support ticket with StableBit regarding the weirdness with the SSD Optimizer plug in.

DrivePool works by creating hidden poolpart folders on one or more drives (e.g. in your case C and D) and pooling them as a single virtual drive (e.g. P), so if the DB needs to be kept on literally C drive you wouldn't be able to directly go "hey DrivePool duplicate C:\PointOfSale to D:\PointOfSale". You could however create a pool drive P from drives C and D, move the database to P:\PointOfSale and then in Windows create a directory symlink so the database still seems to be in C:\PointOfSale as far as your software is concerned. Potential gotchas: If you have to use a symlink because your database has to be in C:\something, some really old software doesn't work with symlinks. It's rare but something to test. You'll need to use DrivePool's real-time duplication and not its scheduled-time duplication as the latter won't duplicate in-use files, but I gather the former is what you're wanting anyway. Personally I would also make sure read striping is disabled, some old software doesn't play nice with that and I wouldn't risk it in a production environment without extensive testing first, but disabling it is as easy as unticking it in the Manage Pool -> Performance menu (if it's ticked in the first place). Note that DrivePool's response to "a drive that's part of the pool has failed" is for the affected pool to go read-only until the failed drive is replaced or at least removed , though that's easy to do. You might also want to look at backup software that supports VSS - i.e. able to take backups of files, folders or drives even when in use. Note that while VSS is not compatible with DrivePool directly it does work on poolpart folders, so if a 2x duplicated pool consisted of 2 poolpart drives then you'd only need to backup one of the poolparts.

The default settings should be emptying the files to the drive with the most free space (in bytes, not percentage) at any given time. So if you have drives A and B with free space A>B then it should be putting the files in A until A<B at which point it should begin putting the files in B until A>B again (and so on)... note that over time this naturally will result in a roughly even spread of files across A and B (assuming the drives are of similar size). Is this not happening? How much free space do you have on each of your archive drives? Also if you're using snapraid or similar parity tool on your archive drives then you'd need to be careful to not have any balancers or placement rules enabled with settings that would move existing files within those drives. Do you have any other Balancers or Placement Rules active?

That's roughly 120 MB/s, which (checking) is about the same as what I get on an internal 12TB SATA HDD that benchmarks at roughly 250 MB/sec sustained, so magic 8-ball says it seems likely?

Both are "Mini-SAS" but the SAS9207-8E requires SFF-8088 cables (rectangle-shaped ends) while the SAS9300-8E requires SFF-8644 cables (square-shaped ends). So the latter is no good to you unless you also buy an adapter. I haven't used the card with Windows/Drivepool however, so if anyone has please do chip in with any tips!

You're welcome! If the backup software does not do so already, you may wish to exclude the hidden system "$RECYCLE.BIN" and "System Volume Information" folders from your backup to save a bit of space there. If you're not using reparse points (symlinks, junctions, etc) inside the pool you could also exclude the ".covefs" system folder.

I haven't used that provider myself; does the tooltip from resting the mouse cursor over each account give any useful distinguishing detail?

Are you familiar with the VHD, VHDX, etc type of file formats that allow a virtual hard drive to be stored as a single file whose actual size expands with the used space of the virtual hard drive it represents? Clouddrive does something similar but instead of a single file it uses multiple files (called chunks, with each chunk roughly equivalent to a number of in-use sectors of the virtual drive). If the clouddrive is kept on local storage (i.e. a physical drive pooled alongside the existing physical drives physical drive or replacing one of them) and you're using backblaze's software to back that up, then it's only going to back up the 1.5TB of the files in the clouddrive. If the clouddrive is kept on blackblaze, then there will also be overhead from the virtual drive metadata plus the cost of any "sectors" that have been used but not (yet) cleaned. Also if clouddrive data duplication (not to be confused with drivepool duplication) is enabled when the clouddrive is created then the storage requirements will be doubled. I hope that's clear? P.S. If your pool consists of four physical drives with 4x drive duplication enabled (i.e. every drive is an exact copy of every other drive) have you looked at whether it's suitable for your situation to have the B2 backup software use the poolpart folder on any one of the drives (which are VSS-compatible) as its source instead of the virtual pool drive?

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.