home *** CD-ROM | disk | FTP | other *** search
/ Complete Linux / Complete Linux.iso / docs / system / filesyst / ext / read.me < prev    next >
Encoding:
Text File  |  1993-03-24  |  6.5 KB  |  169 lines
  1.               README file for the ext file system
  2.  
  3.                 Release 0a12
  4.                   01.01.93
  5.  
  6.                 Remy  Card
  7.                  (card@masi.ibp.fr)
  8.  
  9.  
  10.  
  11.     This file documents the ext file system for Linux and the programs
  12. needed to use this file system
  13.  
  14. The ext file system
  15. ===================
  16.  
  17.     The ext file system is an extension of the minix file system to get rid
  18. of its restrictions.
  19.  
  20.     The ext file system allows :
  21.     - varying length file names from 1 to 255 characters,
  22.     - a maximum of 4 Giga blocks per file system, so the maximum size of
  23.       a file system is 4 Tera bytes,
  24.     - a maximum size of 16 Giga bytes per file,
  25.     - a free blocks/inodes management with a linked list so no more
  26.       disk space is "lost" for bitmaps.
  27.  
  28. Limitations of the ext file system
  29. ==================================
  30.  
  31.     The ext file system is not yet finished and some modifications will
  32. be made in the future.  The current restrictions are :
  33.     - some functions in the code are not very well written,
  34.     - the ext file system is only able to manage 1024 bytes blocks.  Some
  35.       people are working to allow the Linux buffer cache to manage bigger
  36.       blocks.  When it is done, the ext file system will support bigger
  37.       blocks,
  38.     - while the free blocks/inodes lists save space, the performances are
  39.       worse than with a bitmap.
  40.  
  41. Status of the ext file system
  42. =============================
  43.  
  44.     Since release 0.96c, the ext file system has been integrated in Linux.
  45. So, there is nothing to modify in the kernel to use this file system.  However,
  46. this file system is currently in alpha test and may contain some bugs.
  47.  
  48. How to use the ext file system
  49. ==============================
  50.  
  51.     To use the ext file system, you have to get linux 0.96c or latter.
  52. You also need two programs to create a file system and check that it is
  53. consistent.
  54.  
  55.     These two programs can be obtained by anonymous FTP on ftp-masi.ibp.fr
  56. [132.227.64.26] in the file pub/linux/ALPHA/extfs/efsprogs11.tar.Z or on
  57. tsx-11.mit.edu in the file pub/linux/ALPHA/extfs/efsprogs11.tar.Z.  This
  58. file contains the source and binary programs (compiled with GCC 2.2.2d and
  59. linked static) for mkefs (make ext file system) and efsck (ext file system
  60. check).  You can also take the file efsprogs11.src.tar.Z which contains only
  61. the source programs or the file efsprogs11.bin.tar.Z which contains only the
  62. binary programs.
  63.  
  64.     You also need to get the new mount and df command from the latest
  65. rootimage.  These two commands now use the Linux VFS layer and can be used
  66. with any file system integrated in Linux.
  67.  
  68.     Last, you must recompile every program using the readdir() function 
  69. with a version of GCC greater than 2.1 (I suggest using GCC 2.2.2d which is the
  70. "official" C compiler for Linux).  Some programs using readdir() are : the GNU
  71. fileutils, tar, the shells (bash, tcsh, zsh), ...
  72.  
  73. Using an ext file system
  74. ========================
  75.  
  76.     To create an ext file system, you must use the mkefs command. Its
  77. syntax is :
  78.     mkefs [-c | -l filename] [-i bytes_per_inode] /dev/hdXX size_in_blocks
  79.  
  80.     The arguments for mkefs are :
  81.     -c        tests bad blocks on the file system,
  82.     -l file        reads the list of bad blocks from the file,
  83.     -i bpi        specifies the inode ratio.
  84.  
  85.     To mount an ext file system, you must use the new mount command. The
  86. syntax is :    mount -t ext /dev/hdXX /dir
  87.  
  88.     You can also add a line to the file /etc/fstab if you want the ext file
  89. system to be mounted when the system is booted. The format of this line is :
  90.     /dev/hdXX    /dir    ext    defaults
  91.  
  92.     After mounting an ext file system, you can use it by the standard
  93. Linux commands (ls, rm, cp, mv, ...).
  94.  
  95.     You can unmount an ext file system by the command :
  96.         umount /dev/hdXX
  97.  
  98.     You can check an ext file system by using the efsck command. Its syntax
  99. is :
  100.     efsck [-larvsdtS] /dev/hdXX
  101.  
  102.     The arguments for efsck are :
  103.     -l        lists all the file names in the file system
  104.     -a        automaically repairs the file system (use with caution)
  105.     -r        interactively repairs the file system
  106.     -v        verbose execution
  107.     -s        lists the super block informations
  108.     -d        prints debugging output (not very useful except for me
  109.             when I try to find bugs in efsck...)
  110.     -t        tests for bad blocks on the file system
  111.     -S        salvages the blocks/inodes free lists
  112.     -b file        reads the list of bad blocks from the file
  113.  
  114. Important warnings:
  115. -------------------
  116. 1/    efsck comes with NO WARRANTY !! I have written it by using the
  117. minix file system fsck program and it seems to work for me but it has not
  118. been extensively tested.  I do not know is fsck is able to repair every
  119. kind of inconsistency.  I suggest that you don't use the -a parameter.
  120.  
  121. 2/    when efsck discovers problems in the free blocks/inodes linked lists,
  122. it salvages the lists, i.e. rebuilds them.  If efsck rebuilds the lists, there
  123. may problems if the file system is mounted because a copy of the first free
  124. block number and first free inode number is kept in memory for mounted file
  125. systems.  If the lists are salvaged, the first free block and first free inode
  126. can change and be different from the ones kept in memory.  efsck tries to keep
  127. the same first free block/inode but it is not always possible.  When one is
  128. changed, it now prints a warning message.
  129.  
  130. Future work on the ext fs
  131. =========================
  132.  
  133.     I am working to modify the ext file system to add functionalities or
  134. remove some of its limitations :
  135.     - be sure that the efsck program is good and fix its bugs if any,
  136.     - fix bugs reported by alpha-testers,
  137.     - use bigger blocks as soon as the buffer cache will be able to
  138.       manage them, and perhaps use different block sizes in the same
  139.       file system (like fragments in BSD),
  140.     - use bitmaps instead of linked lists to get better performances.
  141.  
  142.     The next release of the ext fs won't be compatible with the current
  143. one, i.e. a current file system won't be managed by the new code.  However,
  144. the new ext fs will be able to coexist with the current one so transition
  145. will be easy.  Moreover, a program will be available to convert a current ext
  146. fs to the new format.
  147.  
  148. How to report bugs
  149. ==================
  150.  
  151.     If you encounters a strange behaviour of the ext file system or of
  152. the mkefs and efsck programs, feel free to report them to me (card@masi.ibp.fr)
  153. so that I can find the bugs and fix them.  It is also a good idea to report
  154. them to the KERNEL channel of the mailing list and I will send the fixes to
  155. this list.
  156.  
  157. Credits
  158. =======
  159.  
  160.     The ext fs code originates in the Minix fs management written by Linus
  161. Torvalds.  Linus also gave some very good advices during the design of the
  162. ext fs.
  163.  
  164.     I'd like to thank all alpha testers who report bugs or success. These
  165. reports help me to improve the ext fs.
  166.  
  167.     Last but not least, my acknowledgements go to Wayne Davison who makes
  168. a good work in mkefs, efsck and the future conversion program.
  169.