Share decreased after moving files between disks

[Cerberus9]

I have a little issue with moving files. I moved files via midnight commander between disks in the array (on the same share), and now I see less space in windows, and in the shares menu in unraid it's messed up aswell.

I heard about data multiplication problem, but that's not the case, I have no duplicates. I tried unbalanced plugin now for some other moving action, and it worked fine, data is moved, but the share is still messed up.

 

I moved like 380GB's of data from disk1 (10TB) to disk4 (4TB) and now I see 10TB less space available, which is concerning. Now set windows aside, because I tried to reattach the share and nothing changed, so I guess the roots of the problem is somewhere in unraid and I failed to get any info on how to fix this. I even stopped the array and started it again, nothing changed.

 

This is what I see in the share menu:

 

And this on the dashboard:

 

I have 2 other shares (they write out the space correctly) which contain like no files: (30GB's max)

 

So something broke on my TORRENT share. Is there any fix for this? If you say server restart I'm gonna eat my hat, because that would be just ridiculous.

 

Sorry if there is already an answer for this but I just couldn't find it anywhere.

Edited February 25 by Cerberus9

[Frank1940]

Quote

 

First thing, you need to click the 'Compute' link (shown by the arrow), to find the amount of storage actually used by the share.   When you do that it will show the storage used and what each disk that contains files associated with that share stored on it. 

 

Second thing, as I recall, the circle is the amount of total space that is available to the share on the array.  If it is less that the total space on the array, this is because the share has restrictions on what disks it can use for storage of data when it does a write operation. 

 

To check/change this setting, click on the Share name on the Shares tab and look for this section:

 

The two settings are circled.  I seem to recall that you should only use one of them-- not both for the same share.  Either include certain disks or exclude certain disks.  (I would do the one which would have the fewest number of selections.)

Edited February 25 by Frank1940

[Cerberus9]

Yes, that's the free space shown, which is not right.

 

I have included all disks and excluded none, not even touched these setting, this is okay for me and moving data should not be affected by this.

Only thing I changed which should still not affect enything because nothing is now splitted on my array:

 

Compute only shows the USED space on the disks, it doesn't make anything else.

[Frank1940]

I run back through your numbers and it does appear that there some discrepancy.    Make sure that there aren't any lost-and-found files anywhere.  Make sure that you refresh the browser window.

 

I don't recall ever seeing any mention of this type of issue before...

 

Now, there is one more thing I want to caution you about.  You stated that you would moving files from Disk Share to Disk Share.  That is fine.  But moving files from Disk Share to User Share (and vice verse) will eventually result in some files being truncated to zero file length.  (This happens when the copy operation is copying a file from and writing it to the same disk.)   mc will allow you to do this.  The 'Dynamix File Manager' plugin will not allow you to do this. 

 

If this does not fix it, post up your Diagnostics file in a new post in this thread. 

[Cerberus9]

Found the issue... Setting the split level affects this...

 

If I set it to manual the size gets messed up, any other automatic setting seems to result in a good outcome, meaning it outputs the size of the share and the free size aswell correctly.

 

However I still don't understand why this is happening.

I did setup a test share now with manual spliting, and it only sees my disk5 which is 8TB's in size... This is next in line for filling up in unraids mind I get this, but why does it break the share size value? I mean it still is set up to use the whole array, so every disk, which is 32TB. I guess it only shows the disks where data is already put, and dinamically changes if more disks are involved... Really strange and kinda missleading in my opinion.

Edited February 25 by Cerberus9
clarifing

[Frank1940]

9 minutes ago, Cerberus9 said:

However I still don't understand why this is happening.

I did setup a test share now with manual spliting, and it only sees my disk5 which is 8TB's in size... This is next in line for filling up in unraids mind I get this, but why does it break the share size value? I mean it still is set up to use the whole array, so every disk, which is 32TB. I guess it only shows the disks where data is already put, and dinamically changes if more disks are involved... Really strange and kinda missleading in my opinion.

 

IF you turn on the help (or click on the 'Split Level', you will get this:

[Cerberus9]

Yeah I figured it out myself already, but who would have thought of this... All settings are kinda self explanatory I didn't even notice the help function there...

Anyways, thanks for taking your time, to look into my silly issue, which turned out to be a user error.

Edited February 25 by Cerberus9

[Frank1940]

By the way, in my opinion, the Split level setting should be left at "Automatically split any directory as required".  The reason being that the other parameter settings causes more problems than they solve with modern hard drives.  They are so large that changing storage location for new files from one drive to another drive occurs so seldom that if a split were to occur that does give an issue, it can be corrected by moving a few files. 

 

More important is the "Minimum free space:" parameter.  It should be set to be larger than any file that is expected to ever be written to the share.  (It is one of those problem areas I was talking about.  The 'Split level' parameter overrides the 'Minimum free space' parameter and it can eventually cause a write operation to fail when a file that is forced to be written this disk won't fit!)  

 

PS--- this parameter was added back in the days when a large HD was 500GB.  The problem occurred when folks were saving material from DVD copies in a folder and file configuration.  As you may realize the movie's video is in several .VOB files of exactly 1GB in size which must be played subsequently.  If these .VOB files get split across two disks, there will be a pause in playback which could occur in the middle of a word!  OF course, this was totally unacceptable...