VERIFICAION DONE And FAILED for Focal.
1. Installed Focal 2. wipefs two devices: one cache and one backing 3. Setup a cache device on a nvme drive (/dev/nvme0n1p1) 4. Setup a backing device a hdd partition (/dev/sdb1) 5. Create a cache setup: sudo make-bcache -B /dev/sdb1 -C /dev/nvme0n1p1 6. Enable proposed and install latest sosreport 7. Generate report with sosreport -a --all-logs # ls -l /dev/sdb1 brw-rw---- 1 root disk 8, 17 Feb 25 22:48 /dev/sdb1 # ls -l /dev/bcache0 brw-rw---- 1 root disk 252, 0 Feb 25 22:48 /dev/bcache0 # dpkg -l | grep sosreport ii sosreport 4.0-1~ubuntu0.20.04.4 amd64 Set of tools to gather troubleshooting data from a system bcache module is loaded: # lsmod | grep bcache bcache 245760 3 crc64 16384 1 bcache But generated sosreport doesn't contain the bcache stats. Looking at the "verbose" output (-v option), bcache plugin isn't triggered at all on Focal. The tests originally done (when submitting patches to upstream) still works with latest bcache.py on Bionic. ** Tags removed: verification-needed-focal ** Tags added: verification-failed-focal -- You received this bug notification because you are a member of STS Sponsors, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1913284 Title: [plugin] [bcache] add a new bcache plugin Status in sosreport package in Ubuntu: Fix Released Status in sosreport source package in Bionic: New Status in sosreport source package in Focal: Fix Committed Status in sosreport source package in Groovy: Fix Committed Status in sosreport source package in Hirsute: Fix Released Bug description: [Impact] Gather bcache stats as part of sos report. Bcache is often deployed as a "frontend" (typically using SSDs) for Ceph cluster's with HDDs to improve performance. When we are dealing with bcache performance or need to debug bcache, these stats are essential to identify the problem. The newly added plugin collects various stats on bcache. [Test Case] It's a new plugin. When sosreport is run on a system with bcache, a number of small files from /sys/fs/bcache and /sys/block/bcache should be collected with this plugin in place. On systems, without bcache, this should be a no-op. [Where problems could occur] Worst case scenarios could be: - As with any plugin, this plugin, in theory, could potentially run indefinitely and timeout. - Affect performance when run on a live system. There's one known case where querying the proiorty_stats [0] had such a problem. But it's not collected as part of this plugin. But otherwise, the stats collection of bcache devices (even if there are many bcache devices deployed on a system) shouldn't affect anything on a live system and shouldn't get anywhere closer to timeout. [Other Info] upstream PR (merged): https://github.com/sosreport/sos/pull/2384 [0] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1840043 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sosreport/+bug/1913284/+subscriptions -- Mailing list: https://launchpad.net/~sts-sponsors Post to : [email protected] Unsubscribe : https://launchpad.net/~sts-sponsors More help : https://help.launchpad.net/ListHelp
