Jump to content
  • 0

"Other" Data but shouldn't be


jsta
 Share

Question

I recently added/removed/replaced some of the drives in my pool with some shucked 8TB WD REDs.

Prior to this, there was only duplicated data with less than 1k of unduplicated data.

 

Now, though, I have 13.6GB "Other" data.

No data is written directly to a disk. They were formatted, added to the pool, and drive letter removed.

 

All data is configured with at least 2x, with some files at 3x duplication.

 

Previously, when I had 11 drives, it was reporting around 2TB "other" data and a bunch of unduplicated. I get re-running "balance" but it did not do anything and continued to report "consistency" issues.

I removed that drive, and it seemed to go back to showing all data was duplicated.

 

Also recently, I occasionally have issues deleting files via Plex or Windows; I get a permission denied.

Regardless, even with that error, sometimes when (attempting) to delete via Windows, despite the error, if I refresh the Explorer window the folder disappears.

Well, it disappears from Explorer, but it's not actually gone.

But then a couple/few minutes later I am able to delete it; so not an actual file permission issue.

 

It also seems that it's more frequently "checking" the pool.

 

I've been running DP for 8 months, and it seems these issues were not persistent prior to my pool getting to >40TB.

 

I'm running the latest GR, 2.1.1.561

 

Also, whether or not it's relevant, after I removed the old 2TB WD Green drives, they all had 2 PoolPart.??? folders. Though it doesn't appear that any of my current drives do (spot-checked half of them)

Link to comment
Share on other sites

Recommended Posts

  • 0

Other data is entirely normal.

http://community.covecube.com/index.php?/topic/37-faq-unduplicated-vs-duplicated-vs-other-vs-unusable/&do=findComment&comment=3635

 

However, the quantity may be problematic.  2TB of "other" is waay too much, unless you're storing data outside of the pool, or have VSS Snapshots enable. 

 

 

As for the deleting stuff, that's a known issue, which any beta build will fix.

 

As for the "checking" the pool, depending on the exact action, this may be normal, as it may be checking to see if the pool needs to be balanced..

 

 

As for the 2 poolpart folders, this can/will happen if you removed the drive and re-added it.  We don't delete these folders, even when removing the drive from the pool.  

 

 

 

And you can find the latest beta build here:

http://dl.covecube.com/DrivePoolWindows/beta/download/StableBit.DrivePool_2.2.0.798_x64_BETA.exe

Link to comment
Share on other sites

  • 0

Having more than a couple megs of "Other" data has been unusual in my particular setup, for the 8 months I've been using DP.

As stated, I removed the drive letters from all the disks, so they are not directly accessible from Explorer.
I also have not stored any data directly on any of the disks.

They are strictly for the drive pool.

 

It was also strange that the amount of unduplicated and other greatly increased when adding disk 11, but then went away after that disk was removed (as it also never balanced properly to the new disk.)

 

As for the duplicate folders; your response would fit the bill. These were 2TB WD Green drives that had excessive LCC/head parking, and I had removed them from the pool so that I could change that idle setting via wdidle. So that would explain that.

 

I was curious if I should update to one of the beta builds. I'll give it a shot.

Thanks.

Link to comment
Share on other sites

  • 0

So I upgraded... since this includes the check-pool-fileparts I figured I'd give that a run...

If I'm reading this correctly, most of the stuff in this folder is duplicated more than configured?

 

This folder is only 2x duplication, but output shows, eg:

 

+ [10x/2x I] Z:\movies\
+ [6x/2x I] Z:\movies\The Shack (2017)
 
Top folder is 10. Sub-folders range from 2-8
 
But results shows nothing is inconsistent.
 
Am I understanding correctly:
  [{0}/{1} IM] {2}
    {0} - The number of file parts that were found for this file / directory.
    {1} - The expected duplication count for this file / directory.
 
Means the first number is the actual number of duplicates, the second number is the expected duplication count (that's configured on the folder), and the I means the expected count is inherited from parent folder?

 

The 5'ish minutes it took to rebalance, after upgrading, the amount of "Other" data changed quite a bit.

 

5 min of balancing:
Other (GB): 10.2 -> 10.5 -> 10.2 -> 11.7 -> 10.6 -> 10.2 -> 11.5 -> 10.1 -> 11.4 -> 10.5 -> 10.1 -> 10.4 -> 10.3 -> 10.2
 
Edit: Looks like it's just the folders that are getting duplicated upwards of 10 times? Not the actual files.
Due to the files being placed on different drives? eg, movie file gets put on disk 1 and 2, but subtitle file gets placed on disk 3 and 4, therefore the folder will exist on 4 disks?
Link to comment
Share on other sites

  • 0

10x/x2 means the folder containing the file is across 10 disks (poolparts) and the file is duplicated twice on 2 of the 10 disks

 

x2 is the expected number of parts

 

if you look at the example in the dpcmd thread it shows a x3/x2 with 3 poolparts and two copies

 

if you have 10 disks the root folder will be on all disks - sub directories may or may not be on all disks as you go down the tree of directories the number of disks containing directories generally decreases down to x2(or more) at the bottom of the tree.

 

In the gui if you put your mouse over each disk in turn it will amongst other things show you how much "other" is on each disk - you might find one disk has a lot more than the others

 

On a pool of 13 disks - i have 16.3gb on another pool of 20 disks i have 11.9GB - it goes up and down while it balances as it moves data from my ssd's to the pool as the "in transit" data gets added to the "other" until its fully copied - hence why you see it going up and down - if its large files being moved you can see the "other" data as its added to a disk "grey" bit which then turns blue when fully copied. Each disk has a few hundred meg of other - mostly ntfs data that you cannot see or access and its only because DP shows it to you that its an "issue" - in normal windows you cant see this data so you dont know its there but it is - its usually the master files records for the disk a database managed by windows all normal as long as its does no get into the multi 10's gb range which it looks like your are not. Also as Chris said if you have data outside the poolparts directory this will be counted as other as well. Also any System Volume Information directories are another culprit with volume snapshots etc (pia mostly)

 

Have fun

Link to comment
Share on other sites

  • 0

yeah I figured out the pool part thing when I output more detail. Makes sense.

 

I also found an errant DP folder on a disk I had apparently removed from the pool and readded.

Folder only contained ~700 meg.

Deleted the folder, and suddenly "Other" data was less than half; from 10.2GB to 4.3GB.

Link to comment
Share on other sites

  • 0

My understanding of "Other" data, is data not contained within the pool.

My "Other" data had finally dropped off, and became non-existent; the "Other" item in the legend of the GUI even disappeared.

 

Well, now I have in total >200GB of "Other" data.

 

I found a drive that's reported as having 100GB of other data.

Yet, when I compare the data usage of the PoolPart folder and drive itself, the difference is less than 3GB.

Which would mean it would contain maybe 3GB worth of "Other" data.

So what would make up the other 97GB?

 

Drive contains: 2,337,532,772,352 bytes

PoolPart folder contains: 2,334,729,968,183 bytes

A difference of only: 2,802,804,169 bytes

which is not even 3GB.

 

Been this way shortly after my previous post.

 

This is running 2.2.0.798

 

Is there a way to report/display any of this?

Find out what data it is reporting as Other?

post-3180-0-38996600-1503019657_thumb.jpg

Link to comment
Share on other sites

  • 0

If you look at the screenshot I attached, I do have show protected folders and show hidden files/folders.

Also, you can see that the PoolPart.GUID folder contains all but 3GB (closer to 2.5GB really) of the data that's stored on the disk.

Yet, DrivePool reports 100GB worth of other data.

 

That would mean either DrivePool is wrong, or there is 97GB worth of data in the pool that it is considering "Other."

Link to comment
Share on other sites

  • 0

If you look at the screenshot I attached, I do have show protected folders and show hidden files/folders.

Also, you can see that the PoolPart.GUID folder contains all but 3GB (closer to 2.5GB really) of the data that's stored on the disk.

Yet, DrivePool reports 100GB worth of other data.

 

That would mean either DrivePool is wrong, or there is 97GB worth of data in the pool that it is considering "Other."

Unfortuantely SVI always shows as Zero size and unless you take ownership of the folder from "system" you can see how big it is - and its not included in your calcs. As chris said its probably VSS snapshots or similar

Link to comment
Share on other sites

  • 0

If I had to wager a guess, the "other" is from VSS Snapshots, and from the directory entries on the drive.  Both of these can/will contribute to the "Other" data.

 

No snapshots. No "Previous Versions" available.

VSS is not being used, not configured, no tasks related to it.

 

Will Windows even write to that folder, if the disk doesn't have a drive letter assigned? Tried searching, but can't seem to find an answer.

Reason being, that 100GB showed up out of nowhere, when the disk had not been assigned a drive letter in a while.

 

Unfortuantely SVI always shows as Zero size and unless you take ownership of the folder from "system" you can see how big it is - and its not included in your calcs. As chris said its probably VSS snapshots or similar

 

Even if that folder is not accessible with a non-system account, any data contained within would be accounted for when viewing data usage of the physical disk.

Data usage reported at the disk level is only 3GB more than data usage within the PoolPart folder.

 

I verified this by examining the C: (OS) drive.

Used space reported at the disk level: 65,229,778,944 (60.7GB)

Used space reported by all (accessible) folders: 27,613,713,072 (25.7GB)

Difference of: 37,616,065,872

Or about 35GB

 

 

Same with my D: (application) drive.

Used space reported at disk level: 244,965,253,120 (228GB)

Used space reported by all (accessible) folders: 147,397,794,179 (137GB)

Difference of: 97,567,458,941

Or about 91GB.

 

Therefore, on this disk in the pool, if the "other" data was contained within the SVI folder, then reported data usage at the disk level would be much greater than data usage at the folder level.

Link to comment
Share on other sites

  • 0

Yes, Windows will write to the drive, even without a drive letter.  It does this by using the "UNC path" (you can see this by running "mountvol").  This is also how our software accesses the drive (so no need for a letter and no practical limit on path size or file name size) 

 

 

As for the used space reporting discrepancies, this looks like it closely matches the other data. 

If that's the case, then it's the "size on disk" vs size reporting that is the cause here. This is what we refer to as "slack space". 

 

Additionally, keep in mind that each directory does actually use up a small bit of space (a cluster each), and this can add up after awhile.  

 

 

Also, it may be worth running a tool like "WinDirStat" to see a full representation of the drive's content. 

Link to comment
Share on other sites

  • 0

Do/will one of the command utilities provide me any info?

 

Size vs Size on Disk has very little difference. As in, the difference is only 7MB.

And it is shown that data usage reported in Disk properties will consist of the data that is within files/folders the user account does not have read access to.

Therefore, with data usage in disk properties and data usage of the folder itself being relatively close (not 100GB difference), the "Other" data being reported must be contained within the PoolPart folder.

 

My DPDisk03:

Disk properties used space: 818GB

PoolPart folder size: 813GB

Other data: 5.43GB

DP reports 813GB duplicated data.

That one matches up with reported info.

 

DPDisk04:
Disk properties used space: 818GB

PoolPart folder size: 808GB

Other data: 6.85GB

DPReports 811GB duplicated data.

 

Those are pretty close.

 

WinDirStat provides the same numbers I've provided.

 

DPDisk06 numbers do not match up.

Reported data for DPDisk06 is not consistent with my other disks, when said data is gathered in the same manner.

Link to comment
Share on other sites

  • 0

The other data is in the svi folder or you have "lost" files - your C drive and D drive figures show a similar discrepancy 35gb and 91gb respectively

 

For example my c drive - OS drive

 

post-2627-0-48905300-1503132442_thumb.jpg

Showing all data used including SVI

 

post-2627-0-96943200-1503132443_thumb.jpg

With sys folders hidden

 

post-2627-0-72526200-1503132444_thumb.jpg

with sys folders visible including SVI - and showing an approx 4gb difference which is in the svi folder and the NTFS master database of files

 

You have much higher differences so you might have other issues or applications (say backup) and system restore points etc etc using space

 

Have you run chkdsk on your drive to make sure you do not have issues?

 

 

Link to comment
Share on other sites

  • 0

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.

Link to comment
Share on other sites

  • 0

...I'll second that.

Without having touched a single file, my Pool changed the measurement dramatically as well, see here: http://community.covecube.com/index.php?/topic/3068-files-not-accessible-via-pool-but-still-there-in-pool-part-folders/&do=findComment&comment=21178

 

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

Link to comment
Share on other sites

  • 0

...really don't know if we are in the same situation here.

At least the way both problems look alike made me post in this thread...but Christopher thinks that this is not the case.

 

EDIT: running that elevated command brought down the "other" from +8TB to 2.7TB now...still way too much. See -> http://imgur.com/a/rI0oH

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.

Link to comment
Share on other sites

  • 0

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

 

 

If you're seeing this, enable logging, and reproduce this:

http://wiki.covecube.com/StableBit_DrivePool_2.x_Log_Collection

 

Upload the logs to us and let us know, as that really shouldn't be happening.  The logs may help indicate why it is.

 

 

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.

 

What version are you on?

 

If you're on any version prior to 2.2.0.710, then that may be the problem. 

 

Both of the public releases have known issues with balancing.  The public beta is actually worse due to some changes to correct issues, ... which cause more inconsistencies, as well as some drift issues.

 

Please make sure you're on one of the more recent builds.  I linked the 2.2.0.798 build below, but that or any newer build should be fine.

 

 

If remeasuring fixes the issue, let me know.  If it doesn't, then enable logging, and remeasure.  

http://wiki.covecube.com/StableBit_DrivePool_2.x_Log_Collection

 

These builds (the 700+ builds) have some additional logging when it comes to measuring to help identify issues.  

 

However, if the issue is that the measuring data is "drifting" and getting out of syn, make sure that you don't have any files open on the pool (eg, check for access via "resmon", and see if there are a lot of writes happening, and reads).  Try closing the files and see if that helps.

 

 

And if you could, run the StableBit Troubleshooter

http://wiki.covecube.com/StableBit_Troubleshooter

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

 

 

If you're seeing this, enable logging, and reproduce this:

http://wiki.covecube.com/StableBit_DrivePool_2.x_Log_Collection

 

Upload the logs to us and let us know, as that really shouldn't be happening.  The logs may help indicate why it is.

 

 

...really don't know if we are in the same situation here.

At least the way both problems look alike made me post in this thread...but Christopher thinks that this is not the case.

 

EDIT: running that elevated command brought down the "other" from +8TB to 2.7TB now...still way too much. See -> http://imgur.com/a/rI0oH

 

As for thsi being the same issue, it may be, but to be blunt .... I'd rather not assume it is.  I would rather treat each and every cast as if it's unique.  If there does happen to be a commonality, then I will notify Alex about that directly, so he can look at the individual cases, and see if there is anything in common.

 

This allows for not only more personalized support, but also, sometimes what appears to be related issues aren't.   It may be the case that these are, but I would rather not assume that.  

Link to comment
Share on other sites

  • 0

If you're seeing this, enable logging, and reproduce this:

http://wiki.covecube.com/StableBit_DrivePool_2.x_Log_Collection

 

Upload the logs to us and let us know, as that really shouldn't be happening.  The logs may help indicate why it is.

 

 

 

What version are you on?

 

If you're on any version prior to 2.2.0.710, then that may be the problem. 

 

Both of the public releases have known issues with balancing.  The public beta is actually worse due to some changes to correct issues, ... which cause more inconsistencies, as well as some drift issues.

 

Please make sure you're on one of the more recent builds.  I linked the 2.2.0.798 build below, but that or any newer build should be fine.

 

 

If remeasuring fixes the issue, let me know.  If it doesn't, then enable logging, and remeasure.  

http://wiki.covecube.com/StableBit_DrivePool_2.x_Log_Collection

 

These builds (the 700+ builds) have some additional logging when it comes to measuring to help identify issues.  

 

However, if the issue is that the measuring data is "drifting" and getting out of syn, make sure that you don't have any files open on the pool (eg, check for access via "resmon", and see if there are a lot of writes happening, and reads).  Try closing the files and see if that helps.

 

 

And if you could, run the StableBit Troubleshooter

http://wiki.covecube.com/StableBit_Troubleshooter

 

 

If you're seeing this, enable logging, and reproduce this:

http://wiki.covecube.com/StableBit_DrivePool_2.x_Log_Collection

 

Upload the logs to us and let us know, as that really shouldn't be happening.  The logs may help indicate why it is.

 

 

 

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.

Link to comment
Share on other sites

  • 0

Okay, thank you for confirming that.

 

 

As for what is causing the issue, I suspect that it's hardware related, but that's .... non-specific... and I could be dead wrong.  So, we try to treat every issue as if it *is* related to our software until proven otherwise.

 

As for the headless system, that does make things problematic (or at least harder).  tools like teamviewer or even VNC may make that a bit easier, though.  But yes, do require another system to be used (or ... if you can tolerate it, a mobile device).

 

 

As for the access, the "SYSTEM" process is a bit odd, IIRC.  

 

 

 

 

And I've flagged both of these issues for Alex (the Developer) here:

https://stablebit.com/Admin/IssueAnalysis/27598

 

 

And if you could get logs (as above), 

And rerun the troubleshooter (using either 3044 or 27598 as the contact ID)?

Link to comment
Share on other sites

  • 0

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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...