Crostini high iowait, apps lock up, terminal crashes after IO-intensive activity
Reported by
spiffyt...@gmail.com,
Sep 20
|
||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; CrOS x86_64 10895.56.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.95 Safari/537.36 Platform: 10895.56.0 (Official Build) stable-channel eve Steps to reproduce the problem: 1. Open the Terminal from Linux Apps 2. Install htop. Set it to show detailed CPU info. 3. In a separate terminal window, run the shell command "cat /dev/zero > zero.txt" 4. Watch htop. Within one minute you should see some CPU cores go 100% grey with IO wait. 5. Cancel the shell command. Watch as IO wait remains high. Notice commands like apt hang. Terminal may eventually crash. What is the expected behavior? Terminal doesn't crash. Terminal commands remain responsive. What went wrong? Something's going nuts with IO in the background. Crashed report ID: How much crashed? Just one tab Is it a problem with a plugin? No Did this work before? No Chrome version: 69.0.3497.95 Channel: stable OS Version: 10895.56.0 Flash Version:
,
Oct 10
,
Nov 2
Chirantan, can you look into this?
,
Nov 2
This is in version 69, where we had some issues with qcow performance. +dverkamp knows more about that. I believe we landed many performance improvements to the disk I/O code since then but I'm not sure how many of those made it into 69. The fix might be to just upgrade to 70 or later. We're also working on sparse disk image support so that we don't have to use qcow at all. This should provide another nice speedup.
,
Nov 2
The main fix for the qcow performance problems was https://chromium-review.googlesource.com/1247441 which landed in 71. The sparse disk image support is tracked in https://crbug.com/893380 - this won't fix existing installations, but new setups on 4.4+ kernels will get raw disks instead of qcow2.
,
Nov 3
Once I'm on 71/72 will these features be behind a feature flag? Can I verify I have the fixes or raw disk support?
,
Nov 3
Problem is still reproducible in v70.
,
Dec 18
To answer the questions from #6, whether you get a raw or qcow2 disk image is determined by testing for support of fallocate(FALLOC_FL_PUNCH_HOLE) - if it is supported on the filesystem that stores the disk image, a raw image is used, and otherwise a qcow2 is used. No additional feature flag is required. For the kernels that ship on Chrome OS devices that support Crostini, this boils down to qcow2 for Linux 3.18 and raw on Linux 4.4 and newer - you can check the kernel for your device on http://dev.chromium.org/chromium-os/developer-information-for-chrome-os-devices Note that if you have an existing qcow2 image, it will not be replaced with a raw image even if your kernel supports FALLOC_FL_PUNCH_HOLE. In addition to the qcow2 performance fix mentioned above, there was another fix for an issue that could cause crashes under high I/O load ( issue 888212 ) that was also merged to v71. Is this still reproducible on v71?
,
Dec 19
I can confirm this behaviour is still there on elm (kernel 3.18) on 72.
,
Dec 19
The terminal became unresponsive after a minute, couldn't even kill the process. |
||||
►
Sign in to add a comment |
||||
Comment 1 by spiffyt...@gmail.com
, Sep 20