Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFE: Parse relevant messages from /dev/kmsg for mount calls #1231

Open
tbzatek opened this issue Dec 5, 2023 · 1 comment
Open

RFE: Parse relevant messages from /dev/kmsg for mount calls #1231

tbzatek opened this issue Dec 5, 2023 · 1 comment

Comments

@tbzatek
Copy link
Member

tbzatek commented Dec 5, 2023

Syscalls (e.g. mount) or writing to certain device files (e.g. /dev/nvme-fabrics) only tend to return errno with no further context. This is too generic and makes users often confused.

The idea here is to open a side channel to /dev/kmsg and read relevant messages that are structured and do provide device context.

6,888,4307125,-;nvme nvme0: creating 6 I/O queues.
 SUBSYSTEM=nvme
 DEVICE=c241:0
6,889,4313950,-;nvme nvme0: mapped 6/0/0 default/read/poll queues.
 SUBSYSTEM=nvme
 DEVICE=c241:0
6,890,4315079,-;nvme nvme0: new ctrl: NQN "nqn.2014-08.org.nvmexpress.boot.poc:test-target", addr 192.168.122.1:4420
 SUBSYSTEM=nvme
 DEVICE=c241:0
3,892,7382617,-;nvme nvme1: failed to connect socket: -110
 SUBSYSTEM=nvme
 DEVICE=c241:1

However, not so many drivers actually provide context.

5,1035,31137642,-;XFS (nvme0n1p2): Mounting V5 Filesystem
6,1036,31157902,-;XFS (nvme0n1p2): Ending clean mount

Since /dev/kmsg is likely a ring buffer, messages need to be filtered out by timestamps. Either read it full (by a non-blocking read) before spawning the syscall or retrieve sequence number from the last record.

There's a high chance of mixing messages from multiple syscalls on the same device. Reliability of such filtering is a question.

@tbzatek
Copy link
Member Author

tbzatek commented Dec 5, 2023

Actually, as of kernel-6.6.2, there's not a single filesystem driver that provides structured messages. Tested btrfs, ext4, f2fs, nilfs, ntfs3, udf and xfs.

Until the situation improves, there's no point of making an attempt to implement this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant