On Fri, Sep 07, 2012 at 11:31:55AM +0200, Thomas Bächler wrote:
> Am 07.09.2012 10:49, schrieb Evangelos Foutras:
> >> I looked into this in the past and intended to suggest the same . If I
> >> remember correctly the installed size savings is 80MB, but if you use
> >> filesystem level compression the savings is only between 10MB and 40MB
> >> (hopefully a future btrfs release will allow us to get numbers with
> >> better precision). Also, the package size becomes smaller if the
> >> modules are not compressed separately, but I forgot exactly by how
> >> much.
> > Just checked with linux-3.5.3-1-x86_64.
> > gzipped modules
> > ---------------
> > package: 42M
> > installed: 59M
> > uncompressed modules
> > --------------------
> > package: 30M
> > installed: 142M
> > I prefer the much smaller installed size myself.
> Thanks for those numbers, that is about how I remember it.
> Regarding Tom's comment about file system level compression: The only
> file system we support that does this is btrfs, which is still
> considered experimental. The .gz compression benefits the majority of
> our users.
> If depmod is buggy regarding the .gz modules, then it should be fixed (I
> remember it behaved inconsistently when mixing compressed and
> non-compressed modules).
I recall this too. kmod's depmod doesn't suffer from this. The library
side does filetype detection on open(), and picks the correct load and
unload functions for that specific file. All of kmod's tools will
magically just do the right thing.
I'm going to assume by the lack of interest in the original post's
content that no one has any objections to the change, and will roll that