https://bugzilla.kernel.org/show_bug.cgi?id=219306 Theodore Tso (tytso@xxxxxxx) changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tytso@xxxxxxx --- Comment #2 from Theodore Tso (tytso@xxxxxxx) --- It/s not true that "nothing is triggering it". What is triggering it systemd-journald, which is apparently calling ftruncate(2) on its log file every single time that writes to the binary log file. I'm not sure why journald is calling ftruncate(2) to the size of the file, but this is causing a call to ext4_setattr(), which is what is calling ext4_truncate. So when you added the printk in the codepath of ext4_truncate(), this causes a kernel log to be emitted, which triggered journald, which then would write into the circular log file /var/log/journal/XXXXXXXXX/system.journal. Why it is repeatedly calling ftruncate(2) in what is apparently a no-op, is unclear to me, but this triggeres another kernel log, which triggers a journald, in an repeated loop. So it is was the very act of adding the printk which caused it to be printed "all the time". Under normal circumstances, this shouldn't be that much of an issue. Now, it is true that we could optimize ftruncate(2) for workloads that are calling truncate very often. Calling ext4_truncate() does involve starting a journal handle, and adding and removing the inode from the orphan list. We just didn't think that there would be programs calling ftruncate(2) in a tight loop with arguments that made it effectively a no-op. It would be possible to add a flag to the in-memory inode if it has been truncated, so that we would know that in the case where the ftruncate(2) is a no-op, we can skip calling ext4_truncate. If fallocate is called on the inode with the FALLOC_FL_KEEP_SIZE, we would clear that in-memroy flag. Other ways of address this, if you really want to track how often ext4_truncate gets called without triggering the journald doom loop would be to use ftrace and/or tracepoints instead of using printk. This is much more efficient, since the log is written into an in-kernel circular buffer, and is then expanded from binary form into human-readable task without having to invoke systemd's journald. And finally, someone could reach out to the systemd developers and ask why they are calling ftruncate(2) in many cases where it appears to be completely unnecessary. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
