Am 02.04.2014 14:27, schrieb Douglas J Hunley: > I was reviewing my Portage settings yesterday and I noticed that I have > PORTAGE_COMPRESS set (to bzip2, the default) on both of my servers and > it occurred to me that both of these servers have filesystems that > support compression (btrfs on one, zfs on the other). So I'm wondering > if it still makes sense to have PORTAGE_COMPRESS set or if I should > unset it and just let the fs-level compression handle it. Portage is > already slow, why have it take the time to do this when the fs does it > better and transparently? Thoughts on the matter? I think you have a good point disabling portage compression, but I wanted to correct one statement: Decompression in the kernel takes as much time as decompression in userspace - if it's the same algorithm. The differences here are: * creation of an additional process (bz[ip2, cat]), negligible compared to the cpu time compression takes * bz[ip2, cat] runs in user space (safer) vs in kernel space ("risky") * different [de]compression algorithm (fs usually uses weaker but faster compression algorithms like lz4, lzo or gz) * different [de]compression setting (portage uses -9, kernel at best -6 - the difference in the resulting file size is small, but the difference in used cpu time is high) For me two things decide the question: * Assuming you write more man pages than you read, and disk space is not an issue, a weaker compression ratio to save cpu time makes sense. * If you have compression _already_ on for the fs, then compressing textual data before storing it on that fs is a waist of cpu time: For example LZ4 will detect already compressed data (compression ratio <12.5%), abort compression and store the file uncompressed. That's nice, but it means that it has already compressed some blocks, before it could measure it - waisting cpu time. Greetings, Daniel -- Get my PGP key at: * http://keyserver.ubuntu.com:11371/pks/lookup?op=get&search=0x837FB8B5BB9D4887 * $ gpg --recv-keys --keyserver keyserver.ubuntu.com 0xBB9D4887