Disk space field in Admin console seriously differs from devices (not ephemeral) |
|||||
Issue descriptionOriginal bug reported by vkhabarov@ in b/109821291. Chrome Version: v65+ OS: Chrome OS Description: "Disk space" in Admin console shows numbers which seriously differ from ones observed on devices, I know there are some similar issue involving Ephemeral mode, but in this case it's not used. What steps will reproduce the problem? 1. Check storage management on Chromebook and df -h 2. Check Device management/Chrome devices/System Activity and Troubleshooting in Admin console What is the expected result? Numbers should be close, only affected by check interval What happens instead? Numbers are completely different Customer observed on Reks - https://drive.google.com/file/d/1iy_8pRcdygwU5uDYoKoJtK-YXHrgyU03/view?usp=sharing https://drive.google.com/file/d/1oM3m9mz_5SktVSaC_J7droQLMVQv45aX/view?usp=sharing === Our repro === Client device (9.0 GB): LR065TYL on fsmaster.com - Filesystem Size Used Avail Use% Mounted on /dev/root 1.7G 1.6G 133M 93% / devtmpfs 2.0G 0 2.0G 0% /dev tmp 2.0G 140K 2.0G 1% /tmp run 2.0G 668K 2.0G 1% /run shmfs 2.0G 8.0M 1.9G 1% /dev/shm /dev/mmcblk0p1 11G 761M 9.0G 8% /mnt/stateful_partition /dev/mmcblk0p8 12M 28K 12M 1% /usr/share/oem /dev/mapper/encstateful 3.1G 56M 3.0G 2% /mnt/stateful_partition/encrypted media 2.0G 0 2.0G 0% /media none 2.0G 0 2.0G 0% /sys/fs/cgroup tmpfs 2.0G 4.0K 2.0G 1% /run/arc/oem tmpfs 2.0G 0 2.0G 0% /run/arc/sdcard tmpfs 2.0G 0 2.0G 0% /run/arc/obb tmpfs 2.0G 0 2.0G 0% /run/arc/media passthrough 2.0G 0 2.0G 0% /run/arc/media/removable /dev/fuse 11G 761M 9.0G 8% /run/arc/sdcard/default/emulated /dev/fuse 11G 761M 9.0G 8% /run/arc/sdcard/read/emulated /dev/fuse 11G 761M 9.0G 8% /run/arc/sdcard/write/emulated On admin console (3.82 GB avalible): https://drive.google.com/file/d/1EsVoMZ5FhvehuHXd9dj9JbMFIstmV-00/view?usp=sharing
,
Jun 7 2018
Assigning to Weifang. There is a certain amount of disk space that is not reflected in the storage management UI, this might be a known issue.
,
Jun 7 2018
Weifang: we actually upload free/total space for every mounted volume as part of device reporting: https://cs.chromium.org/chromium/src/chrome/browser/chromeos/policy/device_status_collector.cc?q=DeviceStatusCollector&sq=package:chromium&g=0&l=111 So this is a reasonable place to add logging to see what's being reported to the server and diff vs what df is reporting.
,
Jun 13 2018
Hi guys, I was wondering if you have an update about this behavior. Customer affected is still waiting to see why the discrepancy is showing between the Google Admin Console and the device itself. Thanks for the help!!
,
Jun 14 2018
@c#3, ah, so it looks the Chrome OS has the potential to report more volume usage details, or is it already reporting it? If it is the latter, should we continue the bug as a server side bug, b/109821291?
,
Jun 20 2018
Hi Team, Is there any update about this know issue? Thanks in advance!!
,
Jun 25 2018
raising priority, because customer has thousands devices reporting incorrect disk space usage.
,
Jun 27 2018
@weifangsun: I've assigned the server side bug, b/109821291, to jiachen@. Feel free to close this bug once you've determined that this is not a client side issue. Thanks.
,
Dec 14
Hello! This bug is receiving this notice because there has been no acknowledgment of its existence in quite a bit of time - If you are currently working on this bug, please provide an update. - If you are currently affected by this bug, please update with your current symptoms and relevant logs. If there has been no updates provided by EOD Wednesday, 12/19/18 (5pm EST), this bug will be archived and can be re-opened at any time deemed necessary. Thank you!
,
Dec 20
Due to lack of action this bug has been Archived. If work is still being done on this issue or you are still experiencing this issue please feel free to re-open with the appropriate information.
,
Dec 20
,
Dec 20
Keeping this bug open as per offline discussion with weifangsun@ that this is still an issue that needs to be tracked. |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by eryen@chromium.org
, Jun 6 2018