Ralf G. R. Bergs wrote:
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.
That reminds me of another question I'm asking myself since a while: It seems
as if you're developing XFS for Linux from scratch instead of "just" porting
it from SGI. Is that right? Or why do you seem to change even fundamental code
pieces? Or does porting to Linux mean you have to rewrite it because it's so
different from IRIX?
I would say 95% of the code is untouched, except for the endian
conversion work which
was neccessary for a little endian implementation. The interfaces
between the vfs and
the filesystem and between the filesystem and the block layer are where
all the
changes have happened. We did need to do a lot of work for data caching
since the
Irix model and the linux model were not at all close. The vfs layer has
some major
differences too.
You could try editing xfs_types.h and changing
#define XFS_BIG_FILES 1
#define XFS_BIG_FILESYSTEMS 1
to
#define XFS_BIG_FILES 0
#define XFS_BIG_FILESYSTEMS 0
I probably can't do that since as you know I use hardware RAIDs so I probably
need "big" filesystems, and I also need "big" files.
The limits in xfs if you turn these off are:
Max file size 2^40 bytes
Max filesystem size is 2 Tbytes I think (not sure without some research).
It does compile and run, and you save about 45K in code size by doing it,
so not too much. You can also edit xfs_macros.h and define WANT_SPACE_C
to 1 (replace the existing definition). This turns a lot of inline
macros into
function calls - it will be slower, but it is another 10K less code -
again, not
very much.
So and smp build (in 2.5) went from
text data bss dec hex filename
520994 4896 2080 527970 80e62 fs/xfs/xfs.o
to
text data bss dec hex filename
487334 4896 2080 494310 78ae6 fs/xfs/xfs.o
with these two build changes.
Steve
|