Problem: - sosreport currently creates a directory, put everything there THEN compress it - This is CPU-intensive, involves an awful lot of unnecessary system calls, involves way more storage than necessary - When a sosreport fails, users willing to provide files to their support team have to create the tarball themselves, when they know how to do that Solution: - Use Tarfile http://docs.python.org/library/tarfile.html - Symlinks and commands outputs can be provided directly through TarFile.add() and TarInfo - All signals need to be catched when possible, to make sure we have a consistent tarball Positive effects: - Less I/O, less operations - A lot less disk space being used - Virtually no temporary files Negative effects: - Back to gzip/bzip2 as TarFile does NOT expose the xz algorithm -- or -- - Compression happens afterwards (partially defeats the purpose of this RFE) Super-cool effect: - (In the long term?) we can stop using /tmp and use the current directory. - Users would have to be very explicitely notified about this change. ... Stuff I didn't think about yet, but please discuss in the comments.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Fixed upstream.
Reverted due to https://github.com/sosreport/sosreport/issues/86
The problem described has been moved upstream in https://github.com/sosreport/sos/issues/944