Hide Forgot
the /sys/block tree contains a lot of information about block devices which isn't present in other forms, including iostats, geometry, alignment, and discard capability information. If this could be included with the standard sosreport generation, it would be helpful for many types of bugs. Thanks, -Eric
Currently, we collect: - output of command "ls -lanR /sys/block" - files "/sys/block/*/queue/scheduler" - for every file (symlink) in /sys/block, collect output of commands: "udevadm info -ap /sys/block/%s" % (disk), "parted -s %s unit s print" % (disk_path), "fdisk -l %s" % disk_path - for every file/symlink starting with "sd" or "hd" (disks), collect output of commands: "hdparm %s" % disk_path, "smartctl -a %s" % disk_path Is some valuable information under /sys/block that is not being collected by either of the commands?
(In reply to Pavel Moravec from comment #2) > Is some valuable information under /sys/block that is not being collected by > either of the commands? Yes. The /sys/block tree contains a lot of information about block devices which isn't present in other forms, including iostats, geometry, alignment, and discard capability information. /sys/block/*/alignment_offset /sys/block/*/discard_alignment /sys/block/*/queue/* would all be useful and are not currently contained in the sosreport, hence this request. Thanks, -Eric
> Is some valuable information under /sys/block that is not being collected by > either of the commands? See the items listed here (among others): https://bugzilla.redhat.com/show_bug.cgi?id=1090483 At the time this was blocked by: https://github.com/sosreport/sos/issues/72 And specifically FC attributes here: https://github.com/sosreport/sos/issues/143 When this last came up this was blocked by #72, and a couple of other smaller issues in the Plugin class file handling that cause problems with collecting sysfs sub-trees. There were also a couple of RHEL6 kernel bugs that meant that grabbing broad swathes under /sys could cause problems. Those should all be fixed now (and if there are any remaining problems we need to address those), so it is just a case of deciding what to add and where. I'm happy to review proposals upstream - if there are still deficiencies in Plugin or Archive we can fix those up in time for 7.4.
Ok, /sys/block/* are indeed symlinks, but does that really preclude grabbing files & values below it? I'm not necessarily asking for the entire tree, but the files reached by the 3 wildcards above would be helpful.
No - not at all - when this was last discussed, we had some bugs in the sos tree copying code that meant we couldn't enable this. Those issues have all been closed upstream since, but the work to expand /sys collection was never finished (the main symlink issue, #72, was closed 18 months ago). There might still be a few minor nits to work out but we've plenty of time to get that done in time for 7.4. I tested this last year and could grab the whole of '/sys' on my test machines without any problems. The specific attributes you mention are certainly not a problem.
Great, thanks for the clarification.
RHEL7.3 has been released. Re-scheduling for potential inclusion in 7.4.
(In reply to Eric Sandeen from comment #3) > (In reply to Pavel Moravec from comment #2) > > > Is some valuable information under /sys/block that is not being collected by > > either of the commands? > > Yes. The /sys/block tree contains a lot of information about block devices > which isn't present in other forms, including iostats, geometry, alignment, > and discard capability information. > > /sys/block/*/alignment_offset > /sys/block/*/discard_alignment > /sys/block/*/queue/* > > would all be useful and are not currently contained in the sosreport, hence > this request. > > Thanks, > -Eric Won't be sufficient information provided by collecting "lsblk -t" output? I see lots of those data collected there.
(In reply to Eric Sandeen from comment #3) > /sys/block/*/alignment_offset > /sys/block/*/discard_alignment > /sys/block/*/queue/* Even collecting those three paths means unacceptable times for systems with >1k block devices - see tests results in https://github.com/sosreport/sos/pull/889#issuecomment-380000769 . I suggest collecting lsblk -tD as a compromise.
Sorry for missing the earlier needinfo. Sure, lsblk -td would provide much of the same information. If you truly have a system with 1000 block devices, it's going to be slow to gather it via any mechanism I think. But lsblk -tD is fine by me if it works for you. Thanks, -Eric
Just a note: instead of collecting "lsblk -tD", sosreport will collect "lsblk -t" and "lsblk -D" separately. The collected information is the same, in summary.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2018:3144