gtsteffaniak
Allocated storage numbers are wrong
Description I'm running v 0.7.14-beta an a Truenas Comunity Edition 25.04 system. I have 3 storage pools and the numbers shown in the sources area are all wrong. See screenshot.
Expected behaviour
What is happening instead?
Additional context This is my config file: server: port: 80 baseURL: "/" logging: - levels: "info|warning|error" sources: - path: "/wd-black-4tb" config: defaultEnabled: true - path: "/wd-black-4tb-4" config: defaultEnabled: true - path: "/usb-ssd" config: defaultEnabled: true userDefaults: preview: image: true popup: true video: false office: false highQuality: false darkMode: true disableSettings: false singleClick: true permissions: admin: false modify: false share: false api: false auth: adminUsername: admin
How to reproduce?
Files
Thanks for opening this, let me explain what has changed recently, so you can help me update the calculations:
In the past, the usage was very simple: it would show the OS reporting for whatever the used & total size for the partition mounted. But I made a change to this recently.
Recently, the total size calculation has not changed. So if you have a partition on a 4TB drive that has a 2.2TB partition that is what you are seeing for total. Does that match your observation?
The second more relevant change was the used size calculation. In the past it was OS's used percentage reporting, but that doesn't make sense anymore with filebrowser quantum, since you normally specific sub folder on a drive -- not the entire drive.
So I changed the used percentage calculation to be the calculated total from indexing -- specific to the source path you configure. This change means that symbolic linked files and folders, hardlinked files and folders, and other special disk volume and types can throw off the reading. When you browse the root of your source in the UI the used size calculation should fully match the folder and files you see in the root directory. Can you confirm if that's the case? I would need your help to understand why its not matching -- whether that's symbolic links or some other reason. You should be able to navigate filebrowser quantum's listing and identify the folders and files why certain folders are "too large" and incorrect. Any additional details you have would help, I could try to create more rules to exclude or duplicate size calculations for these special circumstances.
I happen to have something similar happen every once in a while. I wish I had that amount of space, though.
`server: sources: - path: /mnt/data name: data - path: /mnt/cache name: cache
auth: adminUsername: xxx`
I'm also seeing this, and looking at the files/folders within the source; the totals don't add up anywhere near the total displayed for the source.
Previous versions were correctly displaying just over 29tb used. I have no idea how it's comming up with 1.4pb
The 'backups' source also only has around ~60gb of data on it as well. Both sources shouldn't have any symbolic/hard links, they should be just flat filesystems, though with a few 100k files.
/edit: really odd; I'd been seeing this for a day or two. Then took that screenshot as I was writing this comment. When I finished writing this, I returned to the open filebrowser tab and the totals were suddenly correct. Refreshed the page, restarted the container even; now its jist fine all of a sudden.
Old data in the database from changes in indexing perhaps? Idk, just odd.
yes thats a great example, should total 29TB but shows 1.4PB something is wrong. The calculation should be very simple:
it adds up all the folders and files at root. Thats what the code does. I will take another look.
I think I found the issue, I didn't realize I didn't remove it from where it was being set before by the indexing scheduler... I think that's the issue, ill have that fix in 0.7.15 and you can try again.
The same thing happened to me xD.
I don't have 3.2GB of files, I have around 400MB. Glad that will be fixed.
Edit: I've realized that this happens when I'm on a sub-folder (inside the root folder /). For example if you give another user a "main" folder inside /.
My real storage:
I tried 0.7.14 but its still not correct. Even total seems to be wrong. Why don't you just use total/allocated provided by the OS? To me that would be more logical. Thanks.
It seems that 0.7.15 fixed the allocated size problem for me. I wonder though why to total disk size is shown as 2.2 TB but is in fact 4TB.
The total size is disk partition size not full disk. Is your disk partitioned?
For example, what do you see if you run "lslbk" on the terminal that has the disk?
No, it is not partitioned.
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS nvme0n1 259:0 0 3.6T 0 disk └─nvme0n1p1 259:3 0 3.6T 0 part nvme2n1 259:1 0 3.6T 0 disk └─nvme2n1p1 259:2 0 3.6T 0 part
im going to adjust this in the future, there is another form of measuring the partition size I will use, but it doesn't explain the huge difference you are seeing 2.2TB vs 3.6TB, but perhaps it will work better.
0.7.17 ist still not correct.
Here is what my OS is showing and what filebrowser thiks it is:
I'm not sure what's going on with your total size. FileBrowser is just reading what the OS is telling it. I can't explain why it's different. I'll leave this open in case others have the same issue and might have some explanation
Hi Honestly this is for me a very minor issue Nevertheless this is what mine reports:
532 % …. What does it mean ? Regards Philippe
@stalakerob I don't think that... I'm using btrfs (Main Disk) and ext4 (2nd Disk) as my filesystems and is the same for me.
Hi, I am still using v0.7.14-beta. and have this problem too.
However, I observed that I only get it on the first opening of the Filebrowser. A simple refresh of the page in the browser is fixing the issue. Furthermore, if I logoff and logon again, I don't have the problem neither.
Then it comes again next day...
it must be with the indexing then, something is still off. ill look at it later
Running Quantum in a Docker container and the uploads folder is a mount from my HDD. Occupied space on the disk is around 3.1TB reported by docker exec filebrowser df -h /uploads
v0.8.6-beta
Edit: Please correct me if I'm wrong: I think I understand your reasoning that the bar only displays the used space by the files in the specified folders. For me this was totally unexpected behavior. Reading the percentage bar, I won't get to know any useful information about how much space I have really left on the partition, rather just the sum of all stored files' sizes in Quantum. By this logic, we could leave the partition size off completely, and it would convey the same amount of information, just in a more unambiguous way. My proposal would be the following: Redesign the bar, so it displays 3 stats:
- Total partition size (full length of the bar)
- Used space (filled bar)
- Used space in the folder (part of the filled bar colored in a different way)
We could indicate the meaning of the segments of the bar with color codes explained by a common legend and/or a tool tip.
Running Quantum in a Docker container and the uploads folder is a mount from my HDD. Occupied space on the disk is around 3.1TB reported by
docker exec filebrowser df -h /uploadsv0.8.6-betaEdit: Please correct me if I'm wrong: I think I understand your reasoning that the bar only displays the used space by the files in the specified folders. For me this was totally unexpected behavior. Reading the percentage bar, I won't get to know any useful information about how much space I have really left on the partition, rather just the sum of all stored files' sizes in Quantum. By this logic, we could leave the partition size off completely, and it would convey the same amount of information, just in a more unambiguous way. My proposal would be the following: Redesign the bar, so it displays 3 stats:
- Total partition size (full length of the bar)
- Used space (filled bar)
- Used space in the folder (part of the filled bar colored in a different way)
We could indicate the meaning of the segments of the bar with color codes explained by a common legend and/or a tool tip.
Why not calculate the total available space as [Total partition size] - [Used partition space] = [Available partition space]? In which case the current display will look correct and clear: [Used space in the folder] / [Available partition space] (n%).
