Bug 1389806

Summary: Please include more files from the /sys/block tree in sosreport
Product: Red Hat Enterprise Linux 7 Reporter: Eric Sandeen <esandeen>
Component: sosAssignee: Pavel Moravec <pmoravec>
Status: CLOSED ERRATA QA Contact: Miroslav HradĂ­lek <mhradile>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.3CC: agk, bmr, esandeen, gavin, mhradile, plambri, pportant, sbradley
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
URL: https://github.com/sosreport/sos/pull/889
Whiteboard:
Fixed In Version: sos-3.6-1.el7 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-10-30 10:31:19 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Eric Sandeen 2016-10-28 17:21:24 UTC
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

Comment 2 Pavel Moravec 2016-10-31 07:50:28 UTC
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?

Comment 3 Eric Sandeen 2016-10-31 12:41:51 UTC
(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

Comment 4 Bryn M. Reeves 2016-10-31 12:58:12 UTC
> 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.

Comment 5 Eric Sandeen 2016-10-31 14:39:39 UTC
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.

Comment 6 Bryn M. Reeves 2016-10-31 14:51:12 UTC
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.

Comment 7 Eric Sandeen 2016-10-31 14:51:58 UTC
Great, thanks for the clarification.

Comment 8 Pavel Moravec 2016-11-11 07:55:14 UTC
RHEL7.3 has been released. Re-scheduling for potential inclusion in 7.4.

Comment 9 Pavel Moravec 2017-10-27 12:44:07 UTC
(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.

Comment 10 Pavel Moravec 2018-04-10 12:30:26 UTC
(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.

Comment 11 Eric Sandeen 2018-04-10 12:41:14 UTC
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

Comment 13 Pavel Moravec 2018-06-11 10:02:04 UTC
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.

Comment 17 errata-xmlrpc 2018-10-30 10:31:19 UTC
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