You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm trying to get the best compression from 7z for a large Git repository with lots of small but easily compressible source code files and large binary git-lfs files. I found that without solid mode, compression is very slow and does not fully utilize multithreading. But Keka's solid mode uses the -ms=on parameter, so the archive will only have one solid block.
This means that decompressing or previewing one file from an archive will be very difficult, 7z program must have to read a large part of the compressed file to find the files that need to be decompressed (especially when using the 7zip GUI on Windows that supports partial decompression, or when the compressed files are stored on a HDD). And if a portion of the data in this solid block gets corrupted, I will lose all the files in the archive forever.
Describe the solution you'd like
I would like to see a solid block size configuration option in Keka similar to PeaZip, which would be very useful for advanced users to balance compression time, compression rate and compression file recoverability.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem?
I'm trying to get the best compression from 7z for a large Git repository with lots of small but easily compressible source code files and large binary git-lfs files. I found that without solid mode, compression is very slow and does not fully utilize multithreading. But Keka's solid mode uses the -ms=on parameter, so the archive will only have one solid block.
This means that decompressing or previewing one file from an archive will be very difficult, 7z program must have to read a large part of the compressed file to find the files that need to be decompressed (especially when using the 7zip GUI on Windows that supports partial decompression, or when the compressed files are stored on a HDD). And if a portion of the data in this solid block gets corrupted, I will lose all the files in the archive forever.
Describe the solution you'd like
I would like to see a solid block size configuration option in Keka similar to PeaZip, which would be very useful for advanced users to balance compression time, compression rate and compression file recoverability.
The text was updated successfully, but these errors were encountered: