Community
- Command Central
- MVP Program
- Monthly Mission
- Blogs
- Groups
- Events
- Media Vault
Products
- Observability
- Network Management
- Application Management
- IT Security
- IT Service Management
- System Management
- Database Management
Content Exchange
- SolarWinds Platform
- Server & Application Monitor
- Database Performance Analyzer
- Server Configuration Monitor
- Network Performance Monitor
- Network Configuration Manager
- SQL Sentry
- Web Help Desk
Free Tools & Trials

Linux Diskspace mis-match

Hi There,

Orion reports disk space differently than Linux and I'd like to get them to match. Please review the attached screen prints. Check the and compare the diskspace total, used and available for few of the partition. Like for under putty local/wwmail03data1 shows 825 total & 2.3 GB availbale where as under Solarwinds it shows 885 total and 48 available. Why this difference....how can it be resolved such that solarwinds reports as per the OS reporting (red-hat) ? Please let me know.

Thanks,

Shailesh

Find more posts tagged with

Accepted answers

sean.martinez

We originally had the Volumes Resource using a decimal (base 10) in Orion NPM 9.5 - 9.5.1. We however made the change to 1024ⁿ due to large requests by customers to report Volumes as they would see it on their systems. This is what we have in the Release Notes:

Fixes in Orion NPM Version 10.0

Orion NPM version 10.0 included the following fixes and updates:

-Disk space calculations have been reconfigured to use 1024 instead of 1000 as the sizing factor.

The scenario that customers were seeing was that their average volume used graph on a 30GB drive is showing 32GB when it is at 100%. Using the division by 1024 matches what is seen in Alerting and Reporting as well. When customers were using 1000, they were not getting Alerted correctly. I believe that Linux is the only system using a binary calculation.

All comments

netlogix

Most likely the issue is:

Linux screen shot, 1GB = 1024*1024*1024

NPM: 1GB = 1000*1000*1000

Solarwinds should changed their calculations.

Shailesh1

Is there any changes that I can do under any files in the Solarwinds installation or this is something only Solarwinds can do on a coding level?

mcbridea

I'll prompt a PM to comment on this.

Shailesh1

Appreciate any feedback/update on this.

FormerMember

Most likely the issue is:
Linux screen shot, 1GB = 1024*1024*1024
NPM: 1GB = 1000*1000*1000
Solarwinds should changed their calculations.

SolarWinds is correct, 1GB = 10^9. 1GiB = 2^30, which is what the linux machine is reporting with.

What SolarWinds *should* do is not to change their calculations, but offer the ability to report the values in GB or GiB through a config setting. Its purely a display/preference issue.

netlogix

I get that there is definitions for it, but a standard needs to be established and followed.

Microsoft 2^30
Linux 2^30
Memory 2^30
hard drive 10^9
Mac 10^9

My opinion is once 1 byte = 10^2 or 10^3 or (10^3)/4 (?) (100 or 1000 or 250 (?)) combinations, then we should switch everything to the base 10 system, but computers are based in binary and everything should be explained in binary terms 2^8 = 1 byte, 2^10 = Kilobyte (KB/KiB who cares), 2^20 ...

The only reason to use base 10 is to make it easier for humans and so hard drive companies can claim they give you more space than they really do.

Shailesh1

Hi There,

To Solarwind staff....Is there anyway we can make the disk reporting under Solarwinds similar to that under Linux? Please let us know at the earliest.

Thanks

ctopaloglu

I have the exact same issue. Just opened a case and I get the same response from SolarWinds staff.

OS shows

NPM Shows

Basically SolarWinds staff said that OpenView and OS display (calculates) false values but SolarWinds displays true disk usage information. It's not a bug it's a feature again and again. I can't explain this to anybody! Please fix this ASAP.

arnold.franco

We have the same issue as well at our environment, recently updated the MIB Database on all pollers to see if that makes any difference, but in vein.

mnchetz

we see similar issues in the NPM 12 version too... is there any workaround to fix this?