On Fri 03-03-23 11:38:06, Jan Kara wrote: > On Fri 03-03-23 10:29:39, Jan Kara wrote: > > On Thu 02-03-23 08:37:35, Theodore Ts'o wrote: > > > On Tue, Feb 28, 2023 at 02:58:54PM +0100, Jan Kara wrote: > > > > > > > > Regarding the warning somehow there are dirty pages left after the > > > > procedures freeze_super() goes through to flush all dirty data. That is not > > > > too surprising since in data=journal mode pages get (as a surprise to > > > > freezing code) dirtied when transaction commits. I thought we have this > > > > covered by jbd2_journal_flush() call in ext4_freeze() but maybe there are > > > > some stranded PageDirty bits left? It needs more debugging... > > > > > > So the question I have is whether this is a bug that was always there, > > > or perhaps code changes affected the timing, so that it was much more > > > likely to happen (although in my testing it's still only triggering > > > about 50% of the time). > > > > > > This warning can mean that data can be lost, especially if someone was > > > doing hibernation, right? We can discuss this at today's ext4 video > > > conference, but I'm inclined to wait until the next merge cycle for > > > this patch series until we can figure out what's going on. Jan, what > > > do you think? > > > > As we discussed in the meeting, I'll have a look into the failure. For now > > I'd keep patches on hold as it is not urgent patchset. > > FWIW I'm able to reproduce the issue and also as I'm looking into the > freeze to it was always there in principle. But my patches likely made it > much more probable. I'll have a look what I can do... So in the end this was mostly a cosmetic issue (jbd2 checkpointing code leaving dirty bits on pages whose buffer heads were already written). Patch submitted. Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
