On 2019/8/12 上午10:27, Chris Murphy wrote: > I'm not sure this is a bug, but I'm also not sure if the behavior is expected. > > Test system as follows: > > Intel i7-2820QM, 4/8 cores > 8 GiB RAM, 8 GiB swap on SSD plain partition > Samsung SSD 840 EVO 250GB > kernel 5.3.0-0.rc3.git0.1.fc31.x86_64+debug, but same behavior seen on 5.2.6 > > Test involves using a desktop, GNOME shell, while building webkitgtk. > This uses all available RAM, and eventually all available swap. > > While the build fails on ext4 as well as on Btrfs, the difference on > Btrfs is many btrfs processes taking up quite a lot of cpu resources. > And iotop shows many processes with unexpectedly high read IO. I don't > have enough data collected to be certain, but it does seem on Btrfs > the oom killer is substantially delayed. Realistically, by the time > the system is in this state, practically speaking it's lost. > > Screenshot shows iotop and top state information for this system, at > the time sysrq+t is taken. > > Full 'journalctl -k' output is rather excessive, 13MB uncompressed, > 714K zstd compressed > https://drive.google.com/open?id=1bYYedsj1O4pii51MUy-7cWhnWGXb67XE > > from last sysrq+t > https://drive.google.com/open?id=1vhnIki9lpiWK8T5Qsl81_RToQ8CFdnfU > > last screenshot, matching above sysrq+t > https://drive.google.com/open?id=12jpQeskPsvHmfvDjWSPOwIWSz09JIUlk
This shows it's btrfs endio workqueue, which do the data verification against csum tree. So you see the point, ext* just doesn't support data csum. Thanks, Qu
signature.asc
Description: OpenPGP digital signature
