You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
The text was updated successfully, but these errors were encountered:
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.
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.However, not so many drivers actually provide context.
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.
The text was updated successfully, but these errors were encountered: