		      README file for the ext file system

				Release 0a12
				  01.01.93

				Remy  Card
			     (card@masi.ibp.fr)



	This file documents the ext file system for Linux and the programs
needed to use this file system

The ext file system
===================

	The ext file system is an extension of the minix file system to get rid
of its restrictions.

	The ext file system allows :
	- varying length file names from 1 to 255 characters,
	- a maximum of 4 Giga blocks per file system, so the maximum size of
	  a file system is 4 Tera bytes,
	- a maximum size of 16 Giga bytes per file,
	- a free blocks/inodes management with a linked list so no more
	  disk space is "lost" for bitmaps.

Limitations of the ext file system
==================================

	The ext file system is not yet finished and some modifications will
be made in the future.  The current restrictions are :
	- some functions in the code are not very well written,
	- the ext file system is only able to manage 1024 bytes blocks.  Some
	  people are working to allow the Linux buffer cache to manage bigger
	  blocks.  When it is done, the ext file system will support bigger
	  blocks,
	- while the free blocks/inodes lists save space, the performances are
	  worse than with a bitmap.

Status of the ext file system
=============================

	Since release 0.96c, the ext file system has been integrated in Linux.
So, there is nothing to modify in the kernel to use this file system.  However,
this file system is currently in alpha test and may contain some bugs.

How to use the ext file system
==============================

	To use the ext file system, you have to get linux 0.96c or latter.
You also need two programs to create a file system and check that it is
consistent.

	These two programs can be obtained by anonymous FTP on ftp-masi.ibp.fr
[132.227.64.26] in the file pub/linux/ALPHA/extfs/efsprogs11.tar.Z or on
tsx-11.mit.edu in the file pub/linux/ALPHA/extfs/efsprogs11.tar.Z.  This
file contains the source and binary programs (compiled with GCC 2.2.2d and
linked static) for mkefs (make ext file system) and efsck (ext file system
check).  You can also take the file efsprogs11.src.tar.Z which contains only
the source programs or the file efsprogs11.bin.tar.Z which contains only the
binary programs.

	You also need to get the new mount and df command from the latest
rootimage.  These two commands now use the Linux VFS layer and can be used
with any file system integrated in Linux.

	Last, you must recompile every program using the readdir() function 
with a version of GCC greater than 2.1 (I suggest using GCC 2.2.2d which is the
"official" C compiler for Linux).  Some programs using readdir() are : the GNU
fileutils, tar, the shells (bash, tcsh, zsh), ...

Using an ext file system
========================

	To create an ext file system, you must use the mkefs command. Its
syntax is :
	mkefs [-c | -l filename] [-i bytes_per_inode] /dev/hdXX size_in_blocks

	The arguments for mkefs are :
	-c		tests bad blocks on the file system,
	-l file		reads the list of bad blocks from the file,
	-i bpi		specifies the inode ratio.

	To mount an ext file system, you must use the new mount command. The
syntax is :	mount -t ext /dev/hdXX /dir

	You can also add a line to the file /etc/fstab if you want the ext file
system to be mounted when the system is booted. The format of this line is :
	/dev/hdXX	/dir	ext	defaults

	After mounting an ext file system, you can use it by the standard
Linux commands (ls, rm, cp, mv, ...).

	You can unmount an ext file system by the command :
		umount /dev/hdXX

	You can check an ext file system by using the efsck command. Its syntax
is :
	efsck [-larvsdtS] /dev/hdXX

	The arguments for efsck are :
	-l		lists all the file names in the file system
	-a		automaically repairs the file system (use with caution)
	-r		interactively repairs the file system
	-v		verbose execution
	-s		lists the super block informations
	-d		prints debugging output (not very useful except for me
			when I try to find bugs in efsck...)
	-t		tests for bad blocks on the file system
	-S		salvages the blocks/inodes free lists
	-b file		reads the list of bad blocks from the file

Important warnings:
-------------------
1/	efsck comes with NO WARRANTY !! I have written it by using the
minix file system fsck program and it seems to work for me but it has not
been extensively tested.  I do not know is fsck is able to repair every
kind of inconsistency.  I suggest that you don't use the -a parameter.

2/	when efsck discovers problems in the free blocks/inodes linked lists,
it salvages the lists, i.e. rebuilds them.  If efsck rebuilds the lists, there
may problems if the file system is mounted because a copy of the first free
block number and first free inode number is kept in memory for mounted file
systems.  If the lists are salvaged, the first free block and first free inode
can change and be different from the ones kept in memory.  efsck tries to keep
the same first free block/inode but it is not always possible.  When one is
changed, it now prints a warning message.

Future work on the ext fs
=========================

	I am working to modify the ext file system to add functionalities or
remove some of its limitations :
	- be sure that the efsck program is good and fix its bugs if any,
	- fix bugs reported by alpha-testers,
	- use bigger blocks as soon as the buffer cache will be able to
	  manage them, and perhaps use different block sizes in the same
	  file system (like fragments in BSD),
	- use bitmaps instead of linked lists to get better performances.

	The next release of the ext fs won't be compatible with the current
one, i.e. a current file system won't be managed by the new code.  However,
the new ext fs will be able to coexist with the current one so transition
will be easy.  Moreover, a program will be available to convert a current ext
fs to the new format.

How to report bugs
==================

	If you encounters a strange behaviour of the ext file system or of
the mkefs and efsck programs, feel free to report them to me (card@masi.ibp.fr)
so that I can find the bugs and fix them.  It is also a good idea to report
them to the KERNEL channel of the mailing list and I will send the fixes to
this list.

Credits
=======

	The ext fs code originates in the Minix fs management written by Linus
Torvalds.  Linus also gave some very good advices during the design of the
ext fs.

	I'd like to thank all alpha testers who report bugs or success. These
reports help me to improve the ext fs.

	Last but not least, my acknowledgements go to Wayne Davison who makes
a good work in mkefs, efsck and the future conversion program.
