1

man e2fsck says;

Note that in general it is not safe to run e2fsck on mounted filesystems. The only exception is if the -n option is specified, and -c, -l, or -L options are not specified. However, even if it is safe to do so, the results printed by e2fsck are not valid if the filesystem is mounted. If e2fsck asks whether or not you should check a filesystem which is mounted, the only correct answer is ``no''. Only experts who really know what they are doing should consider answering this question in any other way

I can see (at least ext4) file system errors running journalctl -k. Ostensibly, journalctl gets the same kernel messages as the dmesg utility reports. fsck works differently on each file system, but in general checks the actual fs journal, looks for some other stuff at each inode (iirc). In reading man dmesg, I see mention of a special block device /dev/kmsg and the file /proc/kmsg. I can cat /dev/kmsg and read that information. Is this the same source that journalctl -k gets its data from? How is this related to e2fsck -n?

Improve this question

2 Answers 2

Reset to default
2

journalctl -k shows the messages in the log which came from the kernel. dmesg shows the contents of the kernel ring buffer. Both show errors from the kernel, which include error messages from the file system drivers; those are accurate.

None of this comes from e2fsck. The file system journal has nothing to do with the “journal” accessed by journalctl. Running e2fsck on a mounted file system can produce incorrect results because the data maintained by the file system driver isn’t necessarily on disk when e2fsck is run, and it can change while e2fsck is running.

Improve this answer
4
  • "None of this comes from e2fsck. The file system journal has nothing to do with the “journal” accessed by journalctl" - this is a bit confusing to me because 1) the question did not make this mistake AFAICT 2) the systemd journal in general can include e2fsck messages, it is only that we do not expect journalctl -k to show them. (under normal circumstances, hem, haw). I would just split these two sentences up a little differently.
    – sourcejedi
    May 2, 2019 at 8:04
  • @sourcejedi I thought the journal confusion would explain the question — based on the references to where journalctl gets its info, and “fsck [...] checks the actual fs journal”, I thought the OP perhaps thought that journalctl and the Ext3/4 journal were somehow related. I agree my answer isn’t all that clear, I’ll try to come up with a better way of phrasing it.
    – Stephen Kitt
    May 2, 2019 at 8:10
  • I think this answer hits on the crux of my question. I did some additionally reading and stumbled on this paper that seemed to say that the file system journal is more of an in-memory transaction log, which eventually gets written to the file system itself? Would it be accurate to say that the file system journal for ext4 is both a temporary buffer for writes to the disk as well as a record of the write transactions? The more I think about this, the more I question that logic.
    – Jebel Krong
    May 2, 2019 at 9:32
  • The Ext3 journal is an on-disk data structure which stores transactions. See the Wikipedia article for details and links. The general idea behind journaled file systems is to store changes in a journal, which can then be played to implement the changes; this improves resistance to crashes and power outages etc. The hope is that writes to the journal can be done quickly, and if the system crashes, the journaled writes can be replayed to reduce data loss.
    – Stephen Kitt
    May 2, 2019 at 11:43
0

Sidenote for extra context: during boot, some configurations of systemd will run a fsck command on the root filesystem while it is mounted readonly. As per the warnings in man e2fsck, this is not ideal. The preferred configuration is to use an initramfs which performs a normal fsck before it mounts the root filesystem at all.

(We have an existing Q/A which explains this, but it is a mess).

e2fsck -n on a filesystem which is mounted readonly does print valid results.

Whether the e2fsck without -n is entirely "safe" is another matter. (And if it is not safe, then there is also a risk of invalid results). I would be careful with it :-). But I believe you can trust that what systemd does is not "less safe" than the previous generation of scripts.

I think to reduce the risks, the rule is that if such a fsck had to make any changes, the system should be rebooted immediately.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.