Opening this to track any kind of share usage related issue
Mirko
@Flyer
thanks for your initiative in taking this issue up!
Another observation…rebooting Rockstor and ocationally also while logging in / out of the WebUI the share view looks different, but consistently wrong 
edit: here another one 
Adding a bookmark to this thread, will work on it hopefully soon.
Mirko
1 Like
Hi @glenngould Roland,
I think you’ll probably be my “favourite tester of the day” on this 
eheh
Ok, let’s begin! Asking for @phillxnet brain & eyes too 
First thing I notices :
- We have same shares usage going up&down but we can skip it because these widgets perform sorting over % rather then % and used/total space. We collect shares list with a backbone collection then we sort them by % and we don’t care about used_space/avail_space, so you can have two 0,00% shares and like on last image with emby-config 208KB/10GB before rm_share 18.77MB/7.00TB -> This is expected behaviour / that kind of sort is not coded so no mistakes on this (yes, we can always improve it @phillxnet @glenngould I’m here ready to open an issue )
-
@glenngould shares go up & down (ex. plex-confing, zm13_mysql, etc) but reading this shares list I consider it quite normal: all from Rock-ons aka dockers, so you all “bad guys!”
play with Rock-ons content - think about moving/changing/deleting data to Plex -, but share usage updates occur every x secs and probably we often have current shares usage equal to a previous state. Once again this is normal/expected behaviour - Back to Rock-ons, even if you don’t play with them, those shares don’t handle “static data” ( with static data I mean files like documents, images, etc, etc, etc ), but a “subsystem” so shares content change without users interaction too (example : I run a Rock-on with Plex, I don’t change Plex content, but Plex itself performs some logging, etc)
- Please remember Rock-ons/dockers have some built-in snapshots (check around forum posts for this) and these probably impact shares usage too
This is a starting point and I’m obviously open to suggestions/considerations
First homework for @glenngould : have a big file over Plex, take a snapshot on Plex share from Rockstor WebUI, wait some mins, delete that big file, wait some mins (time required to backend tasks to update shares usage) and check shares usage. Expected behaviour: current content with blue, “ghost” btrfs snapshots content with light blue
Mirko
P.S.: sorry for the delay, going to change job next month so having “nice” working days producing datasheets / migrating techs / boring stuff / etc etc etc 
@Flyer
Thanks Mirko!
Here is the sreenshot before and after I’ve had moved a 4GB file into the plex_config share. Which is strange that the config share seems to be correct with its 44MB. My running Plex server takes care of ~700GB of media (photos, music, videos) I remember that this was once shown with 7GB or so…same with the emby_config share.
Root (should be ~4GB out of 114GB) and rm_share (should be ~1TB out of 7TB) are for sure wrong!
I’m still questioning that all shares/configs are only a few kilobyte, so whyI would need to allocate GB’s 
1 Like
First good point:
shares usage reflects those 4GB (3.97GB)
bad points:
root share not having right size (I hope this is frontend code related rather then btrfs sizes <- if so, I don’t think about a backend code error - @suman had tests on this too and it was ok -, probably more Rock-ons/dockers nature related)
Waiting for screenshots after snapshot & file deleted
Thanks for your help @glenngould
Mirko
@Flyer just to understand it right what I should do…
Simply copy and paste (like before) a big file into plex_config or add a new e.g. big Movie via the webUI of Plex to the library to see any impact on the plex_config share?
Then take a snapshot of the plex_config share and remove the added file -> new screenshot of the dashboard
I’ll be able to perform this test earliest by tomorrow evening or Monday morning when I’m back home.
BTW good luck with your new job 
1 Like
@Flyer
Hi again
so I’ve took again a screenshot before and after copying and after delecting with the same effect in showing somehow correctly the changes.
Strange to me, that the plex_config share shows after this test 5,32MB usage before 8,94MB, nothing done in between with Plex itself, just the 3,85GB file copied and deleted.
Snapshot change looks good or?
Thx
Thanks @glenngould,
snapshot usage is ok, but shares widget not: you should have a light blue bar for those 4.37GB 
Mirko
@glenngould thanks, that’s ok, it’s our expected behaviour 
.
Explanation:
Dark blue bar -> current share “real” content
Light blue bar -> current share “ghost” content (ghost content = data from snapshots exclusive data, like deleted data no more available in your share, but saved with a snapshot)
Suspicion: wrong sizes because of Rock-ons nature (docker): will play with them
Mirko
1 Like