On Tue, Nov 19, 2024 at 03:59:53PM -0800, Krister Johansen wrote: > > Thanks for the additional detail on jbd2's involvement. When I > originally encountered this, it was on a 5.15 kernel where > ext4_commit_super() was still using mark_buffer_dirty() prior to > submitting the IO for the superblock write. I had managed to convince > myself that ext4_commit_super() holding the BH_lock combined with > O_DIRECT waiting for the dirty buffers associated with the superblock to > get written was sufficient to get a consistent read of the superblock. > I missed that this was changed as part of another bugfix[1]. Actually, even in 5.15, ext4_commit_super() only gets used (a) during the mount paths before the journal has been initialized, (b) in the umount code paths after the journal has been shutdown, (c) for file systems without a journal, or (d) when the journal update has failed --- for example, if the journal was aborted due to catastrophic failure. Most of the time during normal operation, say, when the file system is being resized, or the orphan list is being actively manipulated during a huge number of unlinks or truncates, or changing the UUID using EXT4_IOC_SETFSUUID, etc., the kernel updates the superblock using a jbd2 transaction, and not ext4_commit_super(). So the change which you cited in [1] doesn't make a change in practice unless the journal can't be used for some reason. If I remember correctly, the patch submitter for [1] hit the problem they were trying to fix after a journal abort while they were doing fault injection to test I/O error handling. (In other words, case (d) above.) - Ted > [1] https://lore.kernel.org/all/20220520023216.3065073-1-yi.zhang@xxxxxxxxxx/
