jsta

So it's been more than 2 years but... 2016 Essentials is again unable to "see" the GPT DrivePool disk with certain actions. Poking around server health, it reported a number of my "serverfolders" as missing, but they do exist and are accessible. Oddly, not all of them are reported as missing. If I "recreate the folder" it creates it on the D: drive without giving me a choice. I can then try to "move" the folder, but it only allows me to select the C: drive as a new location. If I try to "create new folder" it does allow me to add to the DrivePool disk. I imagine a Windows issue, but it's bazaar. Not sure a reboot clears it up, as the server was just rebooted yesterday.

I only used File Placement rules after the balancer failed to do its job. Balancer did not remove data from disks after de-selecting duplicated and unduplicated for them, then I updated to latest version which experienced the same issue. So I used file placement rules to get the data evacuated. I have not previously used file placement rules, and was only used to evacuate the data off the disks since the balancer did not work properly.

Experiencing the issue with 2.2.2.934, which I got directly from the DP download page yesterday. Upgrading was the first thing I tried File placement rules worked okay, but had to remember to go back in and select the two new disks for every folder.

It is on, yes, but it's under File placement settings and a sub-option of "Balancing plug-ins respect file placement rules." Reads to me like it would only make an impact when using File Placement rules, though, which I don't (normally) use. I did use it yesterday to de-select the 2 drives being replaced though, and it's almost done moving data off.

2 things: First: huh, guess I should have read some release notes huh? Good to know as I was not aware. My fault for not paying attention to notes. Second: I did try to use Disk Usage Limiter. Settings do not get honored, and no data gets evacuated from the disks. That is what I swear I did previously, but is currently not working. Even upgraded to latest official release. Stated in OP

Almost positive Recycle Bin is part of "Other" data, which is stuff not managed by DP. So it shouldn't get balanced. The hidden/system $RECYCLE.BIN folder is at the root of each disk, so is outside the DrivePool folders.

Interesting. Looks like it might should at least work better than the part that isn't currently working. Thanks, I'll give that a shot. Still would be nice to know why it isn't evacuating with the Drive Usage Limiter.

Looking to replace a couple of my drives, and I swear this worked before. Because the removal process locks the pool to read-only, and can take hours (at least in my case it has taken hours), I was previously using the Disk Usage Limiter balancer, and de-selecting Duplicated and Unduplicated for the drives that are being replaced. That would move the data off the drive(s), then the actual removal process would only take a few minutes. Currently though, the balancer settings are not being applied. I was on 2.2.0 something, so went ahead and upgraded to the latest release; 2.2.2.934. Still, de-selecting Duplicated and Unduplicated for the 2 disks, data is not being moved off those drives even after manually starting another rebalance. The GUI does report "New file placement limit (0.0%)" for both disks. Though "Duplicated target for rebalancing" shows -11kb and -37kb (not sure what this actually means though, notation is at the end of the percentage bar) Is there a more efficient way to evacuate data off specific disks prior to replacement, so that the pool doesn't get locked in read-only state for hours on end?

Looks like to can disregard my file lock issue. It apparently is, actually, Plex. 3 different PlexScriptHost processes are (randomly) keeping files open.

Just found that the Windows cmd prompt has an openfiles command to display open files. Seems the option to maintain the object list has to be enabled first, and requires a reboot. Once the Troubleshooter upload submission is complete, I'll reboot for the option to get fully enabled. Next time the issue occurs, I'll query with the openfiles command to see if it will report the actual process that might be locking the file. Or apparently resource monitor can display that info too.

I RDP to my server all the time; but catching the issue can sometimes be problematic since I have to wake up my desktop then RDP, yadda yadda. Regardless of that... File system logging was enabled yesterday evening. Issue is currently occurring; attempting to delete a file, via Plex, a couple dozen times over the last 10 minutes. DrivePool was in the process of "Checking" but I'm unsure if that was already running when I first attempted to delete the file. It is now in the process of duplicating and issue persists. Duplication has completed, but still unable to delete. Just to note that. Also unable to delete directly from DrivePool volume from the server; so it's not a Plex issue. Plex processes don't run under SYSTEM. I don't appear to have any processes or services running as SYSTEM, outside of DrivePool, that should impact file access. At least, nothing that would seemingly hold a file open for >20 minutes (still unable to delete file, and been at least 24 minutes now.) I can still read/stream the file. Troubleshooter is in the process of collecting and uploading data with 3044 as the ID. Service folder has been zipped and has been uploaded to the provided Dropbox link. Also, just to note, the 4GB "Other" data seemingly disappeared again.

I upgraded to 2.2.0.798 when you suggested it with your first response to this thread I'll do my best to upload the logs while the error is occurring. Unfortunately, I tend to only notice it when I'm streaming with Plex and tend to have my desktop in sleep. My server running DP is headless. It may also be coincidental. I am not 100% positive it is being caused by DP, but I have been unable to determine what's accessing the file. All I know is that it tells me the file is in use by SYSTEM. But I'm not seeing the file lock on the network, as Windows does not display the affected file as being open via network connection.

I dunno, your issue does appear to be consistent with the issue I had. ~12.9TB worth of data in your PoolPart folders per WinDirStat. DP reporting only 10.3TB of data between Duplicated and Unduplicated. That leaves the 2.6TB Other unaccounted for; and DP reports 2.64TB Other. So... yeah, it appears to be what I was seeing.

You're also having file access issues? Even with 2.2.0.798, I still occasionally get access denied when deleting a file; and it doesn't matter if it's over the network or directly from the DP volume. I know that was supposed to be fixed in a prior version, but I still have that issue. When it occurs again, I'll have to see if I can still read the file since I haven't tested that. You might try re-measuring. Administrative/elevated command prompt: dpcmd remeasure-pool PoolDriveLetter

I stated I was expecting discrepancies with C: and D: because I know there would be data in the SVI and other OS-protected folders. Again, zero restore points, VSS, etc running. NONE of that. The server is not running any backups of itself. That was just additional "proof" that data usage reported by Disk properties is all-inclusive, regardless of file permissions. Regardless, I forced a re-measure of the pool with dpcmd and "Other" is down to 4.01GB. DP now reports each disk having less than 500MB "Other" data. Including the disk that previously had zero "Other" data. So, yes, there was something wrong with the information DP was reporting. Forcing a re-measure with dpcmd seems to have corrected the reported usage.