add directory bin
This commit is contained in:
gohigh
164
bin/tools-old/efsprogs9.README
Normal file
164
bin/tools-old/efsprogs9.README
Normal file
@@ -0,0 +1,164 @@
|
||||
README file for the ext file system
|
||||
|
||||
Release 0a9
|
||||
04.11.92
|
||||
|
||||
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.
|
||||
|
||||
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/efsprogs9.tar.Z or on
|
||||
tsx-11.mit.edu in the file pub/linux/ALPHA/extfs/efsprogs9.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 efsprogs9.src.tar.Z which contains only the
|
||||
source programs or the file efsprogs9.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
|
||||
|
||||
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 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 (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.
|
||||
Reference in New Issue
Block a user