Ralf G. R. Bergs wrote:
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
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.
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_FILESYSTEMS 1
#define XFS_BIG_FILES 0
#define XFS_BIG_FILESYSTEMS 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.