[MDEV-22752] disks plugin does not work on 32bit systems Created: 2020-05-29  Updated: 2020-06-22  Resolved: 2020-06-16

Status: Closed
Project: MariaDB Server
Component/s: Plugins
Affects Version/s: 10.1, 10.2, 10.3, 10.4, 10.5
Fix Version/s: 10.5.4, 10.1.46, 10.2.33, 10.3.24, 10.4.14

Type: Bug Priority: Major
Reporter: Oleksandr Byelkin Assignee: Rucha Deodhar
Resolution: Duplicate Votes: 0
Labels: None


 Description   

https://buildbot.mariadb.org/#/builders/50/builds/11/steps/5/logs/stdio

it shoud uses size_t instead of long for sizes. Also more tests are welcome.

disks.disks                              w14 [ fail ]
 
        Test ended at 2020-05-29 11:34:19
 
CURRENT_TEST: disks.disks
 
--- /buildbot/32bit-ubuntu-1804/build/plugin/disks/mysql-test/disks/disks.result	2020-05-29 11:23:53.000000000 +0000
 
+++ /buildbot/32bit-ubuntu-1804/build/plugin/disks/mysql-test/disks/disks.reject	2020-05-29 11:34:19.644705159 +0000
 
@@ -9,4 +9,4 @@
 
 ) ENGINE=MEMORY DEFAULT CHARSET=utf8
 
 select sum(Total) > sum(Available), sum(Total)>sum(Used) from information_schema.disks;
 
 sum(Total) > sum(Available)	sum(Total)>sum(Used)
 
-1	1
 
+0	1
 
mysqltest: Result content mismatch



 Comments   
Comment by Vladislav Vaintroub [ 2020-05-29 ]

it should actually use ulonglong, not size_t and especially not long . Never use long, it serves no purpose.
The reason for ulonglong is that disks are bigger than 4GB, even on on 32bit. Even if you count KB, there are now disks that are 4TB big

Comment by Vladislav Vaintroub [ 2020-05-29 ]

size_t total = (info.f_frsize * info.f_blocks) / 1024;
size_t used = (info.f_frsize * (info.f_blocks - info.f_bfree)) / 1024;
size_t avail = (info.f_frsize * info.f_bavail) / 1024;

that stuff needs rethinking , definitely.
not size_t , ulonglong
when multiplying , cast the first parameter to ulonglong, so that multiplication does not result into truncation.

Comment by Rucha Deodhar [ 2020-06-16 ]

Duplicate: https://jira.mariadb.org/browse/MDEV-22834

Generated at Thu Feb 08 09:17:11 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.