sysstat should use stable disk identifiers in stats_disk #195
Comments
msekletar
changed the title
stats_disk
|
I just experienced that and now we cannot identify the disks before and after the reboot. So , maybe sar should try to use the wwid and fallback to major:minor only if there is no info for the wwid (for example VmWare machines without 'disk.enableUUID = "TRUE" ). |
|
So this is probably what I will use in a future sysstat version. I will investigate the point when I have a bit more time. |
|
It will require some planning. |
|
I believe you could simply leave the job to udev |
|
This doesn't work... You got your major:minor in the sar mapped to current udev devices, but after rebooting - sda before is not equal to sda now and 253:8 is not equal to 253:8 after a reboot. |
|
I will try to rephrase What i was proposing is to use the same logic that is used at runtime by IMHO the advantage of using this approach instead of creating a different logic as you seem to propose above is
|
|
So it seems that using Now do we need |
|
I agree with your comment, sar -d -j UUID is better approach, but do we have a logic to get wwid ? WWID is supposed to be unique everywhere and for me is best approach. About binary file containing uuid/wwid - we don't need to probe it every time - maybe sar can listen for udev changes and then updatr it's own cache file ? |
|
Using WWID is OK if I can retrieve it easily for any kind of devices, which is not the case it appears (well, maybe I'm missing something...) I need a clear and reliable way to get the WWID from such an output. Wrt binary file containing UUID/WWID, this is not a question of probing them every time, but really of space used to save them for every sample every time. I was just wondering whether using 16 bytes for every device on every sample to save the UUID/WWID was worth it, knowing that a stable identifier can already be displayed with |
The reason i was making an example with
The issue me and @hunter86bg are facing is not displaying sar files on another machine, but get consistent device names across reboot. on a server system with many devices and a long uptime disks can be added or removed, besides device-mapper and md will always use dynamic major/minor, so just adding a logical volume with lvm will result in device name changing after a reboot.
I'd take the cost, but i understand people with different workloads might not, so i would just add the |
|
Well, what about this way. |
|
OK, thanks for all those ideas. Two things are important regarding the binary datafile though: It should be self-sufficient, and its format must be compatible with older sar versions. |
|
Btw, I don't think that all block device types have WWIDs. IIRC loop devices don't have them. For those, we could possibly store information about the backing file (e.g. inode number, parent block device, path) which was attached to the device at the time when the data was gathered. |
|
I am still not convinced wwid is the way to go, As food for tought here is the content of /dev/disk/by-{id,path} from two different servers:
|
|
Mpath devices are a single LUN accessed over different paths, so in most cases should be treated as one. I know it's a complex problem, but we need a persistent way to recognize a block device before and after a reboot. |
|
FYI I have started to update |
i am willing to test your code on a number of machines, and report results
leave the job to udev :-) |
This patch adds new fields to stats_disk structure to save a stable identifier for each block device (see issue #195). A stable identifier is a name that should not change across reboots for the same physical device. At the present time this stable identifier is the WWN (World Wide Name) id that is read from /dev/disk/by-id if it exists for the device. If it doesn't exist then we fall back on using the pretty name (sda, sda1, etc.). The stable identifier is always collected by sadc when disks statistics are collected (sadc option "-S DISK | XDISK"). It can be printed by sar (or sadf) with the option "-j SID" (SID stands for Stable IDentifier). Signed-off-by: Sebastien GODARD <[email protected]>
|
Commit 22e3fb2 adds support for stable identifiers to |
|
Can you change the "-1" to the actual path of the device like "0x6000c296ab3905dc-[0:0:1:0]" which is visible in multipath , lsscsi & /proc/scsi/scsi: Recently , we got issues where only one of the paths was causing trouble and it was hard to find it based on historical data. |
Currently, the disk activity statistics use
major:minorto associate disk activity with the block device. There are two major drawbacks with this approach:major:minor numbers are not consistent across reboots and sar may associate given disk activity with the different block device after reboot
major:minor are resolved locally and hence portability of the files is problematic. IOW, displaying them with sar on a different machine is close to pointless
I am opening this to start the discussion. Unfortunately, I am not quite sure what other identifiers we could use.
The text was updated successfully, but these errors were encountered: