On 5/13/21 7:15 AM, Theodore Ts'o wrote: > On Thu, May 13, 2021 at 06:42:22PM +0900, Changheun Lee wrote: >> >> Problem might be casued by exhausting of memory. And memory exhausting >> would be caused by setting of small bio_max_size. Actually it was not >> reproduced in my VM environment at first. But, I reproduced same problem >> when bio_max_size is set with 8KB forced. Too many bio allocation would >> be occurred by setting of 8KB bio_max_size. > > Hmm... I'm not sure how to align your diagnosis with the symptoms in > the bug report. If we were limited by memory, that should slow down > the I/O, but we should still be making forward progress, no? And a > forced reboot should not result in data corruption, unless maybe there If you use data=writeback, data writes and journal writes are not synchronized. So, it may be possible that a journal write made it through, a data write didn't - the end result would be a file containing random contents that was on the disk. Changheun - do you use data=writeback? Did the corruption happen only in newly created files? Or did it corrupt existing files? > was a missing check for a failed memory allocation, causing data to be > written to the wrong location, a missing error check leading to the > block or file system layer not noticing that a write had failed > (although again, memory exhaustion should not lead to failed writes; > it might slow us down, sure, but if writes are being failed, something > is Badly Going Wrong --- things like writes to the swap device or > writes by the page cleaner must succeed, or else Things Would Go Bad > In A Hurry). Mikulas _______________________________________________ dm-crypt mailing list -- dm-crypt@xxxxxxxx To unsubscribe send an email to dm-crypt-leave@xxxxxxxx
