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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?




[Index of Archives]     [Linux RAID]     [Linux SCSI]     [Linux ATA RAID]     [IDE]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Device Mapper]

  Powered by Linux