Thread (30 messages) 30 messages, 6 authors, 2020-01-10

Re: [RFC 9/9] __xfs_printk: Add durable name to output

From: Tony Asleson <hidden>
Date: 2020-01-10 16:13:26
Also in: linux-fsdevel, linux-scsi

On 1/8/20 7:41 PM, Alasdair G Kergon wrote:
The goal of this particular project is to maintain a record of the
storage configuration as it changes over time.  It should provide a
quick way to check the state of a system at a specified time in the
past.
This helps with one aspect of the problem, it leaves a bread crumb which
states that at this point in time /dev/sda was the attachment point for
some device, eg. wwn-0x5002538844580000.
The initial logging implementation is triggered by storage uevents and
consists of two components:

1. A new udev rule file, 99-zzz-storage-logger.rules, which runs after
all the other rules have run and invokes:

2. A script, udev_storage_logger.sh, that captures relevant
information about devices that changed and stores it in the system
journal.

The effect is to log the data from relevant uevents plus some
supplementary information (including device-mapper tables, for example).
It does not yet handle filesystem-related events.

Two methods to query the data are offered:

1. journalctl
Data is tagged with the identifier UDEVLOG and retrievable as
key-value pairs.
  journalctl -t UDEVLOG --output verbose
  journalctl -t UDEVLOG --output json
    --since 'YYYY-MM-DD HH:MM:SS' 
    --until 'YYYY-MM-DD HH:MM:SS'
  journalctl -t UDEVLOG --output verbose
    --output-fields=PERSISTENT_STORAGE_ID,MAJOR,MINOR
     PERSISTENT_STORAGE_ID=dm-name-vg1-lvol0

2. lsblkj  [appended j for journal]
This lsblk wrapper reprocesses the logged uevents to reconstruct a
dummy system environment that "looks like" the system did at a
specified earlier time and then runs lsblk against it.
You've outlined how to view and filter on the added data and how to
figure out what the configuration looked like a some point in the past,
that adds one more piece of the puzzle.

However, how would a user simply show all the log messages for a
specific device over time?  It looks like journalctl would need to have
logic added to make this a seamless user experience, yes?

Perhaps I'm missing something that makes the outlined use case above work?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help