README file for the ext file system
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
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
These two programs can be obtained by anonymous FTP on ftp-masi.ibp.fr
[220.127.116.11] in the file pub/linux/ALPHA/extfs/efsprogs10.tar.Z or on
tsx-11.mit.edu in the file pub/linux/ALPHA/extfs/efsprogs10.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 efsprogs10.src.tar.Z which contains only
the source programs or the file efsprogs9.bin.tar.Z which contains only the
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 :
-ctests bad blocks on the file system,
-l filereads the list of bad blocks from the file,
-i bpispecifies 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 :
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 :
You can check an ext file system by using the efsck command. Its syntax
efsck [-larvsdtS] /dev/hdXX
The arguments for efsck are :
-llists all the file names in the file system
-aautomaically repairs the file system (use with caution)
-rinteractively repairs the file system
-slists the super block informations
-dprints debugging output (not very useful except for me
when I try to find bugs in efsck...)
-ttests for bad blocks on the file system
-Ssalvages the blocks/inodes free lists
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 plan 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).
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 ([email protected]
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
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
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.