Christopher (Drashna)

Yeah, it would be nice.  
 
And yeah, some of the advanced tricks that you can do make management of media much easier.

That would do it, actually.  The default threshold for the Prevent Drive Overfill is 90%.  
As for the warning, for the most part it wouldn't be needed. It's an issue when reinstalling or resetting settings only. 
Yeah, just talked to Alex (the Developer) about this, and hopefully we can get this changed sooner, rather than later. 
And it wouldn't turn off... but ideally, we should store all of the balancer settings on the pool.  And either read them from there, or as a backup to be read when it's a "new" pool to the system.  
I mean, we store duplication settings directly in the folder structure, and we store reparse point and other info on the pool as well.  No reason we couldn't store balancing settings (or a copy of it) on the pool, as well.
 
And no worries. It's a legitimate complaint, and one that we should/need to address. 
And glad that Junctions have been awesome for you!  
(junctions on the pool are .. stored on the pool already...  )
Always something, isn't it? 
I'll pass this along and see if we can do something about it. 

OK. As the title suggests I'm not happy.
After 10 days of carefully defragging my 70TB of media (largely 8TB drives), I decided to reinstall my server and have a fresh start on my optimized storage. All neatly organized with full shows that have ended, filling up three 8TB archive drives.
What happens? As someone who has zero interest in the inbuilt balancers and only uses the "Ordered File Placement" plugin, what I didn't expect after reinstalling the OS and then Drivepool was for the fact that every default balancer is enabled by default and ludicrously balancing itself is enabled by default. Why would anyone think that that's a good idea? By the time it's even possible to set a single pool to MY required settings it's already ripped plenty of files from a full 8TB hard drive cos well hey, I guess the whole world wants their drives " leveled out." In which case just remove the "Ordered File Placement" plugin from being available and I will know that DriveBender is the way to go. Like i said all this with the first pool so by the time I get to the 3rd pool? 
I guess it's my own fault for reinstalling my server....not!!
Sorry but I'm pissed off right now!
...(mutters to himself)
 
 

Yup, what Jaga said.
Specifically, the software doesn't automatically rebalance the data like this, unless there is a specific reason to do so (such one or more disks being too full).
Over time, it will accomplish a balanced layout, because new files are added to the disk with the most available free space. 
However, as Jaga indicated, the "Disk Space Equalizer" balancer plugin aggressively rebalances the pool, so that each disk has the same percentage used, or the same amount of free space (your choice).

You'll want to get the "Disk Space Equalizer" plugin for DrivePool from this page, and enable it to force an immediate re-balance.  When it's done, turn it off again and let DrivePool do automatic balancing from then on.

Very nice!

I recently found out these two products were compatible, so I wanted to check performance characteristics of a pool with a cache assigned to it's underlying drives.  Pleasantly, I found there was a huge increase in pool drive throughput using Primocache and a good sized Level-1 RAM cache.
This pool uses a simple configuration: 3 WD 4TB Reds with 64KB block size (both volume and DrivePool).  Here are the raw tests on the Drivepool volume, without any caching going on yet:

 
After configuring and enabling a sizable Level-1 read/write cache in Primocache on the actual drives (Z: Y: and X:), I re-ran the test on the DrivePool volume and got these results:

 
As you can see, not only do both pieces of software work well with each other, the speed increase on all DrivePool operations (the D: in the benchmarks was my DrivePool letter) was vastly greater.  For anyone looking to speed up their pool, Primocache is a viable and effective means of doing so.  It would even work well with the SSD Cache feature in DrivePool - simply cache the SSD with Primocache, and boost read (and write if you use a UPS) speeds.  Network speeds are of course, still limited by bandwidth, but any local pool operations will run much, much faster.
I can also verify this setup works well with SnapRAID, especially if you also cache the Parity drive(s).
I honestly wasn't certain if this was going to work when I started thinking about it, but I'm very pleased with the results.  If anyone else would like to give it a spin, Primocache has a 60-day trial on their software.

A -  Yes, it is - any OS that can read the file system you formatted the drive with (assuming NTFS in this case) can see all it's files.  The files are under a "poolpart..." hidden folder on each drive, fully readable by Windows.
B -  Yes, it will work with Bitlocker.  This is a quote directly from Christopher on these forums:  "You cannot encrypt the DrivePool drive, but you CAN encrypt the disks in the pool."  (Link)

Yes.  The "Remove Disk" option will cause StableBit DrivePool to actively move all of the data from the drive in question to the other drives in the pool.  
You may want to use the "Force damaged disk removal" option, too.  Normally, the removal aborts if it runs into disk errors.  There is a decent chance that you will.... so the "force" option will continue on with the removal and leave the "problem files" on the disk, if any. 

They stay on the disk, outside of the pool, and are considered "other" data.  And nothing will be in the pool.
You want this: 
http://wiki.covecube.com/StableBit_DrivePool_Q4142489
 
As for the existing drive letters, you may want to take a look at this: 
http://wiki.covecube.com/StableBit_DrivePool_Q4822624

Editing my post for a bit more clarity:
You can use duplication and then simply take the drive out of the machine, and revert duplication to x1.  However according to the DrivePool feature list, when you remove a disk from the pool via the software options:
Provided you have enough available space on other disks in the pool, then Christopher is correct in that a removal will transfer all files to other disks prior to removing the drive you wanted.
I'm not sure which option is faster.  Either should work.  Christopher's advice is probably the best you're going to get.

Sounds like something is reading data on the pool, and keeping the drives active. 
Just in case, try disabling "BitLocker_PoolPartUnlockDetect", by setting the "override" value to "false" and rebooting:
http://wiki.covecube.com/StableBit_DrivePool_2.x_Advanced_Settings#Settings.json

Ask someone what the term "spinning rust" means in 20 years and they may look at you funny.   
Let us know how it goes WickedLlama!

Well, the big part is writing here.  That triggers ECC and reallocation in the drive's firmware.  
If that doesn't work, a full format "may".  But if that doesn't work, RMA time. 
By retire, ... well, I have a nice pile of rare earth magnets. 

Good to know, learn something new every day!
 
Now that is an awesome idea.

Not quite.  It's essentially a reverse proxy for the file system.  The commands and processed and forwarded to the underlying drives. 
My (100% blind) guess here is that Oculus is using hardlinks.  That would definitely error out, as we do not support those on the pool. 
But if you could, enable tracing, and reproduce:
http://wiki.covecube.com/StableBit_DrivePool_2.x_Log_Collection
 
Also, if you want a super hacky hack.... install it to "x:\poolpart.xxxxx\Oculus", and then run from the pool.

If the sector has no data in it currently, a secure erase of all empty sectors on the drive would work.  Some tools available to do that can be found here:  https://www.raymond.cc/blog/make-your-recoverable-datas-unrecoverable/
If it has data in it, simply finding the file via a block map tool and deleting it (removing it from the MFT) would mark the sector empty, allowing you to then do a secure erase which would force a write to it.

Are your parity drives the same make/model as your data drives?  Some firmware features aggressively attempt to spin down drives (park heads/sleep) while some are more relaxed.  I had to patch my WD Reds since they were parking heads after just 8 seconds of inactivity, raising the load cycle count unnaturally in a NAS.

From the dumps, that sounds consistent, as "SRV2" is the network share "stack"/driver. 
I think you already have, but try disable Network IO Boost, if you haven't.
That sounds different, but .... hard to tell.  Enable verifier, get a new memory dump, open a ticket and let us know.  Just in case.
I think we already "resolved" yours actually! 
 
 
 
For everyone, (will update main post), try this build:
http://dl.covecube.com/DrivePoolWindows/rc/download/StableBit.DrivePool_2.2.1.925_x64_RC.exe
 
It may not fix the issue, but just in case....

That is absolutely understandable.  I wouldn't want to pay for software that is being abandoned either.
 
That said, we have ABSOLUTELY NO INTENTION OF ABANDONING ANY OF OUR SOFTWARE. 
 
We do apologize for the extreme delay in releases here.  Unfortunately, this is heavily due to StableBit cloudDrive being signfiicantly more complex than we anticipated (the initial public beta was build 240, we're on 834....).   Additionally, we are a small company, and Alex is the only developer at this point.  
 
So for the most part, his effort has been focused on StableBit CloudDrive.  This means that StableBit DrivePool and StableBit Scanner have suffered, in that they haven't gotten much attention (bug fixes). 
 
We know that this isn't good for us or our products, and it leaves things in ... well, a mess.  
 
Once StableBit CloudDrive has a stable release, things will "get better".  After this happens, Alex plans on going through all of the pending issues for both products, and then pushing a public beta and then stable release for those products. 
After that, we have plans on streamlining the development and testing process so that we can have periodic "scheduled" public releases, that are not dependant on Alex's workflow.  So that this never happens again. 
 
And trust me, we are not happy about how things have progressed ourselves... but drastically changing this right now isn't good either, as it could significantly delay a release for StableBit CloudDrive, and it's already been in beta "too long" for us. 
 
 
Additionally, the internal beta builds are very stable, and should be safe to use for production use (myself and many others do). 
 
Further, I have written a "known issues" post, that you can check to see if you want/need to upgrade to a beta build:
http://community.covecube.com/index.php?/topic/1206-stablebit-drivepool-known-issues-and-limitations/
 
 
Yeah, I apologize for that.  Between being swamped by the latest CloudDrive (Google Drive specific) issue, and personal issues (medical and mental stuff), I haven't checked the forums as much as I would like, or should. 
 
 
 
@Spider99, not ignoring you, but I've already referenced/answered what you've said above. 
 
 
This is something that Alex and I have talked about at length, and repeatedly.   
 
So it's something that is DEFINITELY on our minds.  As well, it should be. 
 
There are a number of "solutions" here that we can implement to ensure that we remain afloat.  
Time/version limited licenses (as you've mentioned). Releasing new products periodically to keep revenue up (we have several additional products/services planned already) Release a subscription based product (service), for reliable income. Switch to paid support solutions  
Each one of these options has their pros and cons, and none are mutually exclusive (we could do all of the above).   These are all options that we've discussed internally, and at length.  
 
To be honest, neither Alex nor I are found of the "time/version limited licenses", and prefer to stick to a lifetime license solution. It's a much better experience for users, as it produces less confusion.  And basically it's too late to switch our licensing scheme for existing products (or we'd have to grandfather everyone in).   
 
And as I said, we have several products planned for release already. StableBit CloudDrive is technically included in that, for now. But we have several other products/services planned. Specifically, StableBit FileVault, StableBit Cloud, StableBit PowerGrid and StableBit.me.   These are all additional products/services that will fit in neatly with our existing products, and should provide additional revenue for us.  You can read a bit about these here:
http://wiki.covecube.com/Development_Status
 
(personally, I've been pushing hard for StableBit FileVault for a while now, as it may really address the "bitrot protection" feature that many people want)
 
 
As for ongoing revenue stream, services are .. well, the best option for that. A monthly or yearly payment means continuous revenue stream, as well as offset the price for such a service.  And that would likely be what StableBit Cloud is.  It would not (may not) be self hosted, but we hope that what it does offer would be more than worth it for those interested. 
 
 
 
And as for the paid support, this has been the topic that has been the most heavily debated.  To put this bluntly, even though this is what would directly affect me (paid support, means more money for me directly), I am very much opposed to this.  Other products (competitors) do implement this, and in some cases, I can absolutely understand why ...  I do not like (rather, I hate) the idea of a paywall between customers and good service.   Good tech support is something that should be part of the intrinsic price of the product, not a hidden cost. 
 
However, there are circumstances that I do agree would warrant that paywall.  Such as immediate support (within the hour), remote support to help set up things, etc. 
 
 
 
So, as you can see, this is something that is definitely "on our minds". And it does come up often.  
And this is by far not a complete list of potential actions we can take. It's just the primary ones that we've discussed. 
 
 
@anotherforumname:  I hope this assuages your fears about our software becoming abandonware. Both from an update standpoint, and from a financial one, as well. 
 
 
If you have any more questions, don't hesitate to ask. 

Nope.  Just our drivers.  That way, we can see if/where the issues are occurring in relation to our code. 
Thanks.  Though. I'm not sure which it is.  If you could, open a ticket at https://stablebit.com/contact and mention this ticket.
Correct.  And that's the point here, actually.  The verifier may/will cause it to crash in a different way, because of how it works. 
And looking at the crash type, it's directly related.  The "Pool" part in both types refers to the system memory ("memory pool"), so this does appear to be related. 
 
Oh boy.  That's not good.  And I've flagged that info for Alex, just in case it's helpful.

Unless you're seeing actual corruption, this may be due to "IO" issues. Eg, data not downloading fast enough. 
And if this happened around the time that you created a new drive, then this most likely a timing issue, where the drive was created but not fully usable yet. 
 

I reverted the DP machine to the previous Windows build (1709 + updates), which now has DP 2.2.0.922 on it.
The machine I'm copying FROM still has 1803 on it.
I've copied several files from the 1803 machine to the reverted DP machine without error.
From  https://www.reddit.com/r/sysadmin  Windows 1803 seems to break a lot of things. I'm going to skip it.
 

Hopefully!

im glad im not the only one, im have the same exact issues and i already opened a ticket, hopefully they fix it soon