[Top] [All Lists]

Re: Reduce XFS footprint (was Re: TAKE - remove a function xfs added to

To: "Ralf G. R. Bergs" <rabe@xxxxxxxxxxxxxx>
Subject: Re: Reduce XFS footprint (was Re: TAKE - remove a function xfs added to filemap.c
From: Stephen Lord <lord@xxxxxxx>
Date: Sat, 26 Jan 2002 10:39:24 -0600
Cc: Linux XFS Mailing List <linux-xfs@xxxxxxxxxxx>
References: <E16UTLx-000773-00@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: owner-linux-xfs@xxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226
Ralf G. R. Bergs wrote:

On Sat, 26 Jan 2002 07:33:29 -0600, Steve Lord wrote:

There is now a function in the regular kernel which does what
we need, so use it instead of our own and reduce the xfs footprint
in the mainline kernel code.

Apropos -- is it possible to reduce the XFS footprint (as a module) by throwing in some magic compiler options? I already compile it without debugging option, still it's about 500K in size. Of course I do realize XFS is an extremely powerful (and therefore non-trivial) filesystem but if I remember correctly reiser is only 200K in size.


If you turn off quotas, posix acls, dmapi and realtime (you probably already did these) then it gets a bit smaller. There are definitely other code paths you cannot get to in there
which we could cut out - just a matter of finding them.

You could try editing xfs_types.h and  changing

#define XFS_BIG_FILES           1


#define XFS_BIG_FILES           0

There is no guarantee this will even build on linux to be honest though.
XFS's idea of not supporting BIG_FILES is still large by linux standards
I think. This will get rid of a lot of 64 bit math, but I suspect the places
where we had to work around 64 bit divides and modulo operations will

From what I hear, gcc is not known for optimizing code for size.


<Prev in Thread] Current Thread [Next in Thread>