Question & Answer
Question
Answer
Option | Description | Approximate Size* (1 I/O Group, 30 volumes) |
Approximate Size* (4 I/O Groups, 250 Volumes) |
1 | Standard logs | 10 MB | 340 MB |
2 | Standard logs plus one existing statesave | 50 MB | 520 MB |
3 | Standard logs plus most recent statesave from each node | 90 MB | 790 MB |
4 | Standard logs plus new statesaves† | 90 MB | 790 MB |
*Actual sizes vary based on the number of volumes and managed disks, the software level, and the compressibility of the logs.
† WARNING: Storwize V3500 systems and Storwize V3700 systems with 4 GB of memory per canister might experience application I/O errors when collecting Option 4 if running V7.3 releases between V7.3.0.0 and V7.3.0.8 or V7.4. This issue was resolved under APAR HU00636 in V7.3.0.9 and will be resolved in a future release of V7.4 firmware.
If Option 4 is required to debug your issue, then IBM Support can direct you to an alternative process that generates new statesaves. If you require this procedure then quote support wiki reference FULLDUMPCOLLECTION |
What to consider when you are collecting logs
Two major factors play a part in deciding which logs to send to IBM when you are opening a problem ticket:
- Speed
- Being asked for more logs in the future.
There is no question that collection Option 1 is much faster than Option 4. Option 1 is generated more rapidly, and it is much smaller, so it is quicker to upload it to IBM. However, Option 4 gives the greatest chance that the correct data is uploaded on the first attempt.
It is also worth being aware that not collecting livedumps (Option 4) soon after the problem can reduce the likelihood that the livedump still contains the necessary data to diagnose the problem.
Summary
- For issues related to interoperability with hosts or storage, use Option 4
- For critical performance issues, collect Option 1 and then collect Option 4
- For general performance issues, collect Option 4
- For 2030, 1196 or 1195 errors collect Option 3
- For issues related to compressed volumes, collect Option 4
- For issues related to Metro or Global Mirror, including 1920 errors, collect Option 4 from both systems.
- For all other issues, collect Option 1
If you would prefer to avoid sending multiple data collections to IBM, and the preceding summary suggested uploading Option 1, then you can collect Option 4 while you are uploading Option 1 to IBM. This approach has the following advantages
- IBM can start looking at data much more rapidly because:
- Option 1 takes much less time to collect than Option 4
- Option 1 takes much less time to upload to IBM because of it's size
- By gathering Option 4 as soon as Option 1 finishes, you reduce the likelihood that the data in Option 4 no longer covers the time of the incident. You can then either upload Option 4 immediately, or upload it later when the support team informs you that it is needed for further analysis.
Details
Contents of each bundle
Option 1
This option contains many different log files for both the underlying operating system, and the SVC/Storwize software, including:
- Spectrum Virtualize Event Log
- Spectrum Virtualize Audit Log
- Linux logs including /var/log/messages
These logs are sufficient to diagnose many problems, especially simple hardware replacement procedures
Option 2
This option contains Option 1 plus the single most recent statesave in the system.
On some releases, this option actually collects the most recent dump from the current configuration node. Since this is rarely the information required, customers are advised to choose option 3 instead.
Option 3
This option contains Option 1 plus the single most recent statesave for each node or node canister in the system.
Option 4
This option generates a non-intrusive version of the dump, called a livedump. The livedump is generated on every node or node canister in the system and contains a lot of detailed logging information about the system at this moment in time. This detailed logging information is necessary to analyse certain problems.
The livedump generation can take 10 - 30 minutes to complete.
After the livedump generation is complete, they are collected along with the contents of Option 1.
Note: Taking a livedump can have a small and temporary impact on performance of the system.
Specific Scenarios that require specific log collection
-
- Compressed volume issues - Option 4
- Problems involving hosts - Option 4
- Problems involving Storage Subsystems - Option 4
- Problems involving Metro or Global Mirror, including Error Code 1920 - Option 4 from both systems
- 2030 Error, 1196 error or 1195 error - do not collect Option 4
-
- If you have a single one of the preceding errors, then Option 4 does not collect the required information. If you choose Option 4 in this case, then support will ask you to manually collect the necessary dump files, rather than using the support package.
Collect Option 3.
- If you have a single one of the preceding errors, then Option 4 does not collect the required information. If you choose Option 4 in this case, then support will ask you to manually collect the necessary dump files, rather than using the support package.
- Simple Hardware replacement - Option 1
-
- It is very rare for support teams to need Option 4 for hardware replacements.
V7000 Gen1 systems might require Option 4 for complex hardware issues, or for root cause analysis.
- It is very rare for support teams to need Option 4 for hardware replacements.
- Problems involving performance
-
- Option 1 contains detailed performance statistics for the last 16 intervals (normally 1 hr 20 minutes). These logs can be used to diagnose many performance issues. However, in more complex cases, the livedumps that were collected in Option 4 may be necessary
If the performance issue is not critical, then sending just Option 4 is the most expedient solution.
If the problem needs to be looked at as soon as possible, then sending Option 1 followed by Option 4 can enable IBM to start looking at the problem more rapidly.
- Option 1 contains detailed performance statistics for the last 16 intervals (normally 1 hr 20 minutes). These logs can be used to diagnose many performance issues. However, in more complex cases, the livedumps that were collected in Option 4 may be necessary
Glossary
- Statesave - The term statesave is used to mean either a dump or a livedump
- Livedump - A livedump is a binary data capture that collects the current state of the software with minimal impact to I/O operations. The contents of a livedump are similar to the contents of a dump
- Dump - A dump file is collected when the software restarts for some reason. It is similar in nature to a core file, and can be used to understand why the software restarted
Was this topic helpful?
Document Information
Modified date:
28 March 2023
UID
ssg1S1005029