Transparent Decompression Support For EXT4
Phoronix: Transparent Decompression Support For EXT4
A Mozilla engineer has been developing transparent decompression support for the EXT4 file-system to benefit Firefox on Android, among other use-cases...
ehhhh it may have its uses, but modifying the kernel for your user app? really?
Actually the topic of a generic compression / decompression framework in kernel got brought up in the lz4 discussion. this may be the first step towards getting it
Originally Posted by pheldens
Why backport btrfs features to ext4 when you could just work on getting btrfs mainstream-ready? (yeah, I know Android would never switch filesystem at this point). Also, I'm curious why Android isn't looking at f2fs considering Samsungs work to make it really good for the kind of internal flash phones use.
Reminds me of the good old days of DoubleDisk in MS-DOS 6.
I don't have statistics, but I'd wager that the greater bulk of kernel contributions are made with specific use cases as the primary motivator. I don't think that just because this particular one targets improved performance for a single app makes it any less legitimate a reason for the work. This work has the potential to benefit a great deal more use cases than just the one that is trying to be improved through this effort.
Originally Posted by pheldens
Is there any advantage of this over upx? http://upx.sourceforge.net/
UPX compresses executable binaries.
Originally Posted by TheOne
So UPX would be good, for example, to compress "/usr/bin/firefox" (or "/usr/libexec/firefox-bin", depending on your distro ;-) )
This is used to compress dynamically loaded libraries (.so files), which is not and can't be supported by UPX (due to the way libraries are loaded).
So this would be good, for exemple to compress "/usr/lib64/xulrunner/libxul.so"
Think of it as a UPX-for-SO-files, which need to be put into the kernel so it intercepts the necessary hooks.
(Like UPX, and unlike BTRFS' various Zlib/LZO/LZ4 compressors, files need to be compressed in advance offline
Also the decompression happens at a very last step in the file system when the .so file is being streamed into memory. It doesn't work with memory maps or seeks.
Only this time the decompressor is in the filesystem module and not embed inside the so-file (like upx on elfs) because that simply is technically impossible).
Note that, on windows, UPX *IS* able to compress DLL files, because they function completely differently.
(They are basically just a different type of executable, the same PE/COFF format as used in the .EXE files, and are loaded and executed the same).
It also doesn't decompress all the bytes properly, but this is on purpose to gain speed, on average the decompression mangles about 1% of the file contents while gaining 3% of speed. You can even gain up to 7% of speed if you're OK with the decompression overwriting some parts of some near-by files, to enable this pass the "elephant-in-the-vessel-store" option. But since the project is in alpha the numbers aren't final yet.