[LWN Logo]

Subject: Large-File support of 32-bit Linux v0.01 available!
To:	linux-kernel@vger.rutgers.edu
Date:	Mon, 21 Dec 1998 13:40:35 +0200 (EET)
From:	Matti Aarnio <matti.aarnio@sonera.fi>

Hello,

  Folks keep telling that
	1) "we need large file support on intel Linux"
	2) "it is too difficult to do efficiently, you must do
	    lots of rework in kernel"
	3) "you will need new system calls, and new libraries"
  and
	4) nobody *doing* the thing

  So, I decided to have a burst of madness, and do about 50% of
  the grunt kernel work.  (It needed about 50 hours of work, of
  which circa 20 went for hunting two braindo bugs I made..
  /sbin/init  didn't even start with them, so it was relatively
  easy to see that there was a bug -- *somewhere*)


  Place:

	ftp://mea.tmt.tele.fi/linux/LFS/

  What it is now able to do is:
	- Extended page cache up to 16 TB (16384 GB) file sizes
	  at i386 architecture
	- Doing it by scaling page-offset variable (u_long) in
	  the page-cache datastructure by PAGE_SHIFT -- 4096 at i386.
	- Expanding all file offsets and their uses in fs/*.c mm/*.c,
	  and fs/*/*.c to new  loff_t  type (64-bit: long long)


  So far my experiences with this have been *only* kernel compiles,
  e.g. I have not had time to try to do seeking beyond 2G marker,
  and then write there.

  What needs to be done:
	- LFS spec needs various new system calls.  Many can be
	  implemented with suitable simple wrappers over old ones,
	  but some will need new entry vectors.
	  (And at 64-bit systems those *64() calls are just aliases
	   to pre-existing calls..)
	- Testing !
	- NFS needs fixing (see comments at the v0.01 patch)
	  That last one is trivial thing..


/Matti Aarnio <matti.aarnio@sonera.fi>
-- End of included mail.

----- End of forwarded message from The Post Office -----

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/