On 8/11/21 9:55 PM, Jens Axboe wrote: > > That is very interesting. Like Olivier mentioned, it's not that actual > commit, but rather the change of behavior implemented by it. Before that > commit, we'd hit the async workers more often, whereas after we do the > correct retry method where it's driven by the wakeup when the page is > unlocked. This is purely speculation, but perhaps the fact that the > process changes state potentially mid dump is why the dump ends up being > truncated? > > I'd love to dive into this and try and figure it out. Absent a test > case, at least the above gives me an idea of what to try out. I'll see > if it makes it easier for me to create a case that does result in a > truncated core dump. > If it helps, a "good" coredump from my program is about 350 MB compressed down to about 7 MB by bzip2. A truncated coredump varies in size from about 60 KB to about 2 MB before compression. The program that receives the coredump uses bzip2 to compress the data before writing it to disk. Tony
