On Sun, Jun 23, 2024 at 06:57:13PM -0700, Alexander Coffin wrote: > [1.] One line summary of the problem: > Using resize2fs on-line resizing on a specific ext4 partition is > causing an Oops. > > > [6.] Output of Oops.. message (if applicable) with symbolic information > resolved (see Documentation/admin-guide/bug-hunting.rst) > > ``` > [ 445.552287] ------------[ cut here ]------------ > [ 445.552300] kernel BUG at fs/jbd2/journal.c:846! Thanks for the bug report. The BUG_ON is from the following assert in jbd2_journal_next_log_block: J_ASSERT(journal->j_free > 1); and it indicates that we ran out of space in the journal. There are mechanisms to make sure that this should never happen, and if the journal is too small and the transaction couldn't be broken up, then the operation (whether it is a resize or a file truncate or some other operation) should have errored out, and not triggered a BUG. We'll need to investigate further how to address this, but a short-term workaround is to simply to make the journal size larger. It looks like this is a very small file system, and so mke2fs will by default use a smaller journal so that the overhead of the journal doesn't overwhelm the usuable space for that small file system. This can result in a performance degredation, but that was considered an acceptable tradeoff rather than users getting annoyed that there very small file system had an unaccepted file system overhead of say, 75% of the usable space. Very often these small file systems was on crapola devices such as USB thumb drives, where performance was going to be a diaster anyway. :-) In practice, people have generally not tried to resize small file systems like this, which is why we hadn't run into this situation earlier. Cheers, - Ted
