lostecho/oldlinux-files
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

add directory study

Browse Source
This commit is contained in:
gohigh
2024-02-19 00:25:23 -05:00
parent b1306b38b1
commit f3774e2f8c
4001 changed files with 2285787 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

83
study/sabre/os/files/FileSystems/ext2fs/ext2fs_1.html Normal file
View File

@@ -0,0 +1,83 @@
<!-- X-URL: http://step.polymtl.ca/~ldd/ext2fs/ext2fs_1.html -->
<!-- This HTML file has been created by texi2html 1.29
from ext2fs.texi on 3 August 1994 -->
<TITLE>Analysis of the Ext2fs structure - Introduction</TITLE>
<P>Go to the <A HREF="ext2fs_2.html">next</A> section.<P>
<P>
Copyright (C) 1994 Louis-Dominique Dubeau.
<P>
You may without charge, royalty or other payment, copy and distribute
copies of this work and derivative works of this work in source or
binary form provided that:
<P>
(1) you appropriately publish on each copy an appropriate copyright
notice; (2) faithfully reproduce all prior copyright notices included in
the original work (you may add your own copyright notice); and (3) agree
to indemnify and hold all prior authors, copyright holders and licensors
of the work harmless from and against all damages arising from the use
of the work.
<P>
You may distribute sources of derivative works of the work provided
that:
<P>
(1) (a) all source files of the original work that have been modified,
(b) all source files of the derivative work that contain any party of the
original work, and (c) all source files of the derivative work that are
necessary to compile, link and run the derivative work without
unresolved external calls and with the same functionality of the
original work ("Necessary Sources") carry a prominent notice explaining
the nature and date of the modification and/or creation. You are
encouraged to make the Necessary Sources available under this license in
order to further development and acceptance of the work.
<P>
EXCEPT AS OTHERWISE RESTRICTED BY LAW, THIS WORK IS PROVIDED WITHOUT ANY
EXPRESS OR IMPLIED WARRANTIES OF ANY KIND, INCLUDING BUT NOT LIMITED TO,
ANY IMPLIED WARRANTIES OF FITNESS FOR A PARTICULAR PURPOSE,
MERCHANTABILITY OR TITLE. EXCEPT AS OTHERWISE PROVIDED BY LAW, NO
AUTHOR, COPYRIGHT HOLDER OR LICENSOR SHALL BE LIABLE TO YOU FOR DAMAGES
OF ANY KIND, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
<P>
<H1><A NAME="SEC1" HREF="ext2fs_toc.html#SEC1">Introduction</A></H1>
<P>
This document has been written by Louis-Dominique Dubeau. It contains
an analysis of the structure of the Second Extended File System and is
based on a study of the Linux kernel source files. This document does
not contain specifications written by the Ext2fs development team.
<P>
Ext2fs was designed by
R<EFBFBD>my Card <A NAME="FOOT1" HREF="ext2fs_foot.html#FOOT1">(1)</A>
as an extensible and powerful file system for Linux. It is also the most
successful file system so far in the Linux community.
<P>
The first Linux file system was Minixfs: a file system originally
developed for the Minix operating system. This file system had many
disadvantages. Among them was: the 64MB limit on partitions, the 14
characters limit on file names and no built in extensibility.
<P>
To overcome those problems,
R<EFBFBD>my Card
wrote extfs. This file system was mostly based upon the original Minixfs
code and implementation. However, it removed the 64MB size limit on
partitions, and increased the file name size limit to 255 characters.
<P>
In his quest for the perfect file system,
R<EFBFBD>my
was still unsatisfied. So he decided to write an brand new file system:
ext2fs. This file system not only has the advantages of extfs but also
provides a better space allocation management, allows the use of special
flags for file management, the use of access control lists and is
extensible.
<P>
Will someday
R<EFBFBD>my
come up with ext3fs? Who knows? However, in the meantime ext2fs is
<STRONG>the</STRONG> de-facto standard Linux file system. This document describes
the physical layout of an ext2 file system on disk and the management
policies that every ext2 file system managers should implement. The
information in this document is accurate as of version 0.5 of ext2fs
(Linux kernel version 1.0). The information about access control lists
is not included because no implementation of ext2fs enforce them anyway.
<P>
<P>Go to the <A HREF="ext2fs_2.html">next</A> section.<P>

49
study/sabre/os/files/FileSystems/ext2fs/ext2fs_10.html Normal file
View File

@@ -0,0 +1,49 @@
<!-- X-URL: http://step.polymtl.ca/~ldd/ext2fs/ext2fs_10.html -->
<!-- This HTML file has been created by texi2html 1.29
from ext2fs.texi on 3 August 1994 -->
<TITLE>Analysis of the Ext2fs structure - Error Handling</TITLE>
<P>Go to the <A HREF="ext2fs_9.html">previous</A>, <A HREF="ext2fs_11.html">next</A> section.<P>
<A NAME="IDX48"></A>
<A NAME="IDX49"></A>
<H1><A NAME="SEC10" HREF="ext2fs_toc.html#SEC10">Error Handling</A></H1>
<P>
This chapter describes how a standard ext2 file system must handle
errors. The superblock contains two parameters controlling the way
errors are handled. See section <A HREF="ext2fs_4.html#SEC4">Superblock</A>
<P>
The first of these is the <CODE>s_mount_opt</CODE> member of the superblock
structure in memory. Its value is computed from the options specified
when the fs is mounted. Its error handling related values are:
<P>
<DL COMPACT>
<DT><CODE>EXT2_MOUNT_ERRORS_CONT</CODE>
<DD>continue even if an error occurs.
<P>
<DT><CODE>EXT2_MOUNT_ERRORS_RO</CODE>
<DD>remount the file system read only.
<P>
<DT><CODE>EXT2_MOUNT_ERRORS_PANIC</CODE>
<DD>the kernel panics on error.
</DL>
<P>
The second of these is the <CODE>s_errors</CODE> member of the superblock
structure on disk. It may take one of the following values:
<P>
<DL COMPACT>
<DT><CODE>EXT2_ERRORS_CONTINUE</CODE>
<DD>continue even if an error occurs.
<P>
<DT><CODE>EXT2_ERRORS_RO</CODE>
<DD>remount the file system read only.
<P>
<DT><CODE>EXT2_ERRORS_PANIC</CODE>
<DD>in which case the kernel simply panics.
<P>
<DT><CODE>EXT2_ERRORS_DEFAULT</CODE>
<DD>use the default behavior (as of 0.5a <CODE>EXT2_ERRORS_CONTINUE</CODE>).
</DL>
<P>
<CODE>s_mount_opt</CODE> has precedence on <CODE>s_errors</CODE>.
<P>Go to the <A HREF="ext2fs_9.html">previous</A>, <A HREF="ext2fs_11.html">next</A> section.<P>

16
study/sabre/os/files/FileSystems/ext2fs/ext2fs_11.html Normal file
View File

@@ -0,0 +1,16 @@
<!-- X-URL: http://step.polymtl.ca/~ldd/ext2fs/ext2fs_11.html -->
<!-- This HTML file has been created by texi2html 1.29
from ext2fs.texi on 3 August 1994 -->
<TITLE>Analysis of the Ext2fs structure - Formulae</TITLE>
<P>Go to the <A HREF="ext2fs_10.html">previous</A>, <A HREF="ext2fs_12.html">next</A> section.<P>
<H1><A NAME="SEC11" HREF="ext2fs_toc.html#SEC11">Formulae</A></H1>
<P>
Here are a couple of formulae usually used in ext2fs managers.
<P>
The block number of a file relative offset:
<P>
block = offset / s_blocksize
<P>
<P>Go to the <A HREF="ext2fs_10.html">previous</A>, <A HREF="ext2fs_12.html">next</A> section.<P>

17
study/sabre/os/files/FileSystems/ext2fs/ext2fs_12.html Normal file
View File

@@ -0,0 +1,17 @@
<!-- X-URL: http://step.polymtl.ca/~ldd/ext2fs/ext2fs_12.html -->
<!-- This HTML file has been created by texi2html 1.29
from ext2fs.texi on 3 August 1994 -->
<TITLE>Analysis of the Ext2fs structure - Invariants</TITLE>
<P>Go to the <A HREF="ext2fs_11.html">previous</A>, <A HREF="ext2fs_13.html">next</A> section.<P>
<H1><A NAME="SEC12" HREF="ext2fs_toc.html#SEC12">Invariants</A></H1>
<P>
Here we define a set of invariant propositions. These propositions can
be momentarily false during file manipulations in the ext2 file system
manager. However, file invariants should be always be true for the set
of files not currently manipulated by the file system manager. File
system invariants should always be true when the file system manager is
not currently manipulating the file system.
<P>
<P>Go to the <A HREF="ext2fs_11.html">previous</A>, <A HREF="ext2fs_13.html">next</A> section.<P>

10
study/sabre/os/files/FileSystems/ext2fs/ext2fs_13.html Normal file
View File

@@ -0,0 +1,10 @@
<!-- X-URL: http://step.polymtl.ca/~ldd/ext2fs/ext2fs_13.html -->
<!-- This HTML file has been created by texi2html 1.29
from ext2fs.texi on 3 August 1994 -->
<TITLE>Analysis of the Ext2fs structure - File Invariants</TITLE>
<P>Go to the <A HREF="ext2fs_12.html">previous</A>, <A HREF="ext2fs_14.html">next</A> section.<P>
<H2><A NAME="SEC13" HREF="ext2fs_toc.html#SEC13">File Invariants</A></H2>
<P>
<P>Go to the <A HREF="ext2fs_12.html">previous</A>, <A HREF="ext2fs_14.html">next</A> section.<P>

9
study/sabre/os/files/FileSystems/ext2fs/ext2fs_14.html Normal file
View File

@@ -0,0 +1,9 @@
<!-- X-URL: http://step.polymtl.ca/~ldd/ext2fs/ext2fs_14.html -->
<!-- This HTML file has been created by texi2html 1.29
from ext2fs.texi on 3 August 1994 -->
<TITLE>Analysis of the Ext2fs structure - File System Invariants</TITLE>
<P>Go to the <A HREF="ext2fs_13.html">previous</A>, <A HREF="ext2fs_15.html">next</A> section.<P>
<H2><A NAME="SEC14" HREF="ext2fs_toc.html#SEC14">File System Invariants</A></H2>
<P>Go to the <A HREF="ext2fs_13.html">previous</A>, <A HREF="ext2fs_15.html">next</A> section.<P>

30
study/sabre/os/files/FileSystems/ext2fs/ext2fs_15.html Normal file
View File

@@ -0,0 +1,30 @@
<!-- X-URL: http://step.polymtl.ca/~ldd/ext2fs/ext2fs_15.html -->
<!-- This HTML file has been created by texi2html 1.29
from ext2fs.texi on 3 August 1994 -->
<TITLE>Analysis of the Ext2fs structure - References</TITLE>
<P>Go to the <A HREF="ext2fs_14.html">previous</A>, <A HREF="ext2fs_16.html">next</A> section.<P>
<H1><A NAME="SEC15" HREF="ext2fs_toc.html#SEC15">References</A></H1>
<P>
Here are cited the sources used to write this document. Everything is
cited: books, sources, man pages, etc.
<A NAME="FOOT4" HREF="ext2fs_foot.html#FOOT4">(4)</A>
<P>
Card, R<>my 1993. <EM>Impl<EFBFBD>mentation du syst<73>me de fichiers ext2 dans Linux</EM>,
Rapport MASI, Institut Blaise Pascal, Paris, France.
<P>
Card, R<>my, et al. 1994. The ext2fs sources in Linux kernel. Available
by ftp at nic.funet.fi.
<P>
Card, R<>my, Ts'o, Theodore and Tweedie, Stephen. 1994. <EM>Linux File
Systems</EM>. Available at
ftp://ftp.ibp.fr/pub2/linux/packages/ext2fs/ext2-1.eps.gz
<P>
Torvalds, Linus, et al. 1994. The Linux 1.0 kernel sources. Available
by ftp at nic.funet.fi.
<P>
Ts'o, Theodore, and Card, R<>my. 1994. The e2fsprogs-0.5a sources. Available
by ftp at sunsite.unc.edu
<P>
<P>Go to the <A HREF="ext2fs_14.html">previous</A>, <A HREF="ext2fs_16.html">next</A> section.<P>

76
study/sabre/os/files/FileSystems/ext2fs/ext2fs_16.html Normal file
View File

@@ -0,0 +1,76 @@
<!-- X-URL: http://step.polymtl.ca/~ldd/ext2fs/ext2fs_16.html -->
<!-- This HTML file has been created by texi2html 1.29
from ext2fs.texi on 3 August 1994 -->
<TITLE>Analysis of the Ext2fs structure - Concept Index</TITLE>
<P>Go to the <A HREF="ext2fs_15.html">previous</A> section.<P>
<H1><A NAME="SEC16" HREF="ext2fs_toc.html#SEC16">Concept Index</A></H1>
<P>
<DIR>
<H2>a</H2>
<LI><A HREF="ext2fs_8.html#IDX44">Access path</A>
<LI><A HREF="ext2fs_7.html#IDX39">ACL inode</A>
<H2>b</H2>
<LI><A HREF="ext2fs_7.html#IDX36">Bad blocks list</A>
<LI><A HREF="ext2fs_4.html#IDX20">Bitmap cache</A>
<LI><A HREF="ext2fs_6.html#IDX22">Bitmaps, in general</A>
<LI><A HREF="ext2fs_6.html#IDX23">Block allocation and bitmaps</A>
<LI><A HREF="ext2fs_6.html#IDX24">Block bitmap</A>
<LI><A HREF="ext2fs_2.html#IDX1">Blocks, in general</A>
<LI><A HREF="ext2fs_7.html#IDX40">Boot loader inode</A>
<H2>c</H2>
<LI><A HREF="ext2fs_4.html#IDX21">Caching of bitmaps</A>
<LI><A HREF="ext2fs_3.html#IDX17">Content of a group</A>
<LI><A HREF="ext2fs_7.html#IDX33">Content of an inode</A>
<LI><A HREF="ext2fs_8.html#IDX47">Current directory</A>
<H2>d</H2>
<LI><A HREF="ext2fs_2.html#IDX3">Definition of a block</A>
<LI><A HREF="ext2fs_2.html#IDX11">Definition of a fragment</A>
<LI><A HREF="ext2fs_8.html#IDX43">Directories, in general</A>
<LI><A HREF="ext2fs_8.html#IDX45">Directory entries</A>
<LI><A HREF="ext2fs_3.html#IDX15">Duplication of information</A>
<H2>e</H2>
<LI><A HREF="ext2fs_10.html#IDX49">Error handling</A>
<LI><A HREF="ext2fs_10.html#IDX48">Errors, in general</A>
<H2>f</H2>
<LI><A HREF="ext2fs_7.html#IDX42">First normal inode</A>
<LI><A HREF="ext2fs_2.html#IDX13">Fragment size</A>
<LI><A HREF="ext2fs_2.html#IDX2">Fragments, in general</A>
<H2>g</H2>
<LI><A HREF="ext2fs_3.html#IDX14">Groups, in general</A>
<H2>i</H2>
<LI><A HREF="ext2fs_3.html#IDX16">Information duplication</A>
<LI><A HREF="ext2fs_6.html#IDX25">Inode allocation and bitmaps</A>
<LI><A HREF="ext2fs_6.html#IDX26">Inode bitmap</A>
<LI><A HREF="ext2fs_7.html#IDX32">Inode content</A>
<LI><A HREF="ext2fs_7.html#IDX28">Inode layout</A>
<LI><A HREF="ext2fs_7.html#IDX31">Inode structure</A>
<LI><A HREF="ext2fs_7.html#IDX27">Inodes, in general</A>
<H2>l</H2>
<LI><A HREF="ext2fs_3.html#IDX18">Layout of a group</A>
<LI><A HREF="ext2fs_7.html#IDX29">Layout of a inode</A>
<LI><A HREF="ext2fs_7.html#IDX35">List of bad blocks</A>
<LI><A HREF="ext2fs_2.html#IDX10">Logical addresses range</A>
<LI><A HREF="ext2fs_2.html#IDX8">Logical block size</A>
<LI><A HREF="ext2fs_2.html#IDX6">Logical versus physical addresses</A>
<LI><A HREF="ext2fs_2.html#IDX5">Logical versus physical blocks</A>
<H2>p</H2>
<LI><A HREF="ext2fs_8.html#IDX46">Parent directory</A>
<LI><A HREF="ext2fs_2.html#IDX7">Physical blocks</A>
<H2>r</H2>
<LI><A HREF="ext2fs_2.html#IDX4">Reserved blocks</A>
<LI><A HREF="ext2fs_7.html#IDX38">Root directory</A>
<LI><A HREF="ext2fs_7.html#IDX37">Root inode</A>
<H2>s</H2>
<LI><A HREF="ext2fs_2.html#IDX12">Size of a fragment</A>
<LI><A HREF="ext2fs_2.html#IDX9">Size of logical blocks</A>
<LI><A HREF="ext2fs_7.html#IDX34">Special inodes</A>
<LI><A HREF="ext2fs_7.html#IDX30">Structure of an inode</A>
<H2>t</H2>
<LI><A HREF="ext2fs_4.html#IDX19">Times</A>
<H2>u</H2>
<LI><A HREF="ext2fs_7.html#IDX41">Undelete directory inode</A>
</DIR>
<P>
<P>Go to the <A HREF="ext2fs_15.html">previous</A> section.<P>

71
study/sabre/os/files/FileSystems/ext2fs/ext2fs_2.html Normal file
View File

@@ -0,0 +1,71 @@
<!-- X-URL: http://step.polymtl.ca/~ldd/ext2fs/ext2fs_2.html -->
<!-- This HTML file has been created by texi2html 1.29
from ext2fs.texi on 3 August 1994 -->
<TITLE>Analysis of the Ext2fs structure - Blocks and Fragments</TITLE>
<P>Go to the <A HREF="ext2fs_1.html">previous</A>, <A HREF="ext2fs_3.html">next</A> section.<P>
<A NAME="IDX1"></A>
<A NAME="IDX2"></A>
<H1><A NAME="SEC2" HREF="ext2fs_toc.html#SEC2">Blocks and Fragments</A></H1>
<A NAME="IDX3"></A>
<P>
Blocks are the basic building blocks of a file system. The file system
manager requests to read or write from the disk are always translated to
a query to read or write an integral number of blocks from the disk.
<A NAME="IDX4"></A>
<P>
Some blocks on the file system are reserved for the exclusive use of the
superuser. This information is recorded in the <CODE>s_r_blocks_count</CODE>
member of the superblock structure. See section <A HREF="ext2fs_4.html#SEC4">Superblock</A> Whenever the total
number of free blocks becomes equal to the number of reserved blocks,
the normal users can no longer allocate blocks for their use. Only the
superuser may allocate new blocks. Without this provision for reserved
blocks, filling up the file system might make the computer unbootable.
Whenever the startup tasks would try to allocate a block, the computer
would crash. With reserved blocks, we ensure a minimum space for booting
and allowing the superuser to clean up the disk.
<A NAME="IDX5"></A>
<A NAME="IDX6"></A>
<A NAME="IDX7"></A>
<A NAME="IDX8"></A>
<A NAME="IDX9"></A>
<P>
This is all very simple. However, computer scientists like to
complicates things a bit. There are in fact two kinds of blocks, logical
blocks and physical blocks. The addressing scheme and size of these two
kind of blocks may vary. What happens is that when a request is made to
manipulate the range <SAMP>`[a,b]'</SAMP> of some file, this range is first
converted by the higher parts of the file system into a request to
manipulate an integral number of logical blocks: <SAMP>`a'</SAMP> is rounded
down to a logical block boundary and, <SAMP>`b'</SAMP> is rounded up to a
logical block boundary. Then, this range of logical blocks is converted
by lower parts of the file system into a request to manipulate an
integral number of physical blocks. The logical block size must be the
physical block size multiplied by a power of two <A NAME="FOOT2" HREF="ext2fs_foot.html#FOOT2">(2)</A>. So when going from logical to physical addressing
we just have to multiply the address by this power of two.
<A NAME="IDX10"></A>
<P>
The logical addresses of the file system goes from zero up to the total
number of blocks minus one. Block zero is the boot block and is usually
only accessed during special operations.
<P>
Now, the problem with blocks is that if we have a file that is not an
integral number of blocks, space at the end of the last block is wasted.
On average, one half block is wasted per file. On most file systems this
means a lot of wasted space.
<A NAME="IDX11"></A>
<A NAME="IDX12"></A>
<A NAME="IDX13"></A>
<P>
To circumvent this inconvenience, the file system uses fragments. The
fragment size must be the physical block size multiplied by a power of
two <A NAME="FOOT3" HREF="ext2fs_foot.html#FOOT3">(3)</A>. A file is therefore a sequence of
blocks followed by a small sequence of consecutive fragments. When a file
has enough ending fragments to fill a block, those fragments are grouped
into a block. When a file is shortened, the last block may be broken into
many contiguous fragments.
<P>
The general relationship between sizes is:
<P>
<P>Go to the <A HREF="ext2fs_1.html">previous</A>, <A HREF="ext2fs_3.html">next</A> section.<P>

38
study/sabre/os/files/FileSystems/ext2fs/ext2fs_3.html Normal file
View File

@@ -0,0 +1,38 @@
<!-- X-URL: http://step.polymtl.ca/~ldd/ext2fs/ext2fs_3.html -->
<!-- This HTML file has been created by texi2html 1.29
from ext2fs.texi on 3 August 1994 -->
<TITLE>Analysis of the Ext2fs structure - Groups</TITLE>
<P>Go to the <A HREF="ext2fs_2.html">previous</A>, <A HREF="ext2fs_4.html">next</A> section.<P>
<A NAME="IDX14"></A>
<H1><A NAME="SEC3" HREF="ext2fs_toc.html#SEC3">Groups</A></H1>
<A NAME="IDX15"></A>
<A NAME="IDX16"></A>
<P>
The blocks on disk are divided into groups. Each of these groups
duplicates critical information of the file system. Moreover, the
presence of block groups on disk allow the use of efficient disk
allocation algorithms.
<A NAME="IDX17"></A>
<A NAME="IDX18"></A>
<P>
Each group contains in that order:
<P>
<UL>
<LI>the superblock. See section <A HREF="ext2fs_4.html#SEC4">Superblock</A>
<P>
<LI>the group descriptors. See section <A HREF="ext2fs_5.html#SEC5">Group Descriptors</A>
<P>
<LI>the block bitmap of the group. See section <A HREF="ext2fs_6.html#SEC6">Bitmaps</A>
<P>
<LI>the inode bitmap of the group.
<P>
<LI>the inode table of the group. See section <A HREF="ext2fs_7.html#SEC7">Inodes</A>
<P>
<LI>the data blocks in the group. See section <A HREF="ext2fs_2.html#SEC2">Blocks and Fragments</A>
</UL>
<P>
The superblock and group descriptors of each group must carry the same
values on disk.
<P>Go to the <A HREF="ext2fs_2.html">previous</A>, <A HREF="ext2fs_4.html">next</A> section.<P>

231
study/sabre/os/files/FileSystems/ext2fs/ext2fs_4.html Normal file
View File

@@ -0,0 +1,231 @@
<!-- X-URL: http://step.polymtl.ca/~ldd/ext2fs/ext2fs_4.html -->
<!-- This HTML file has been created by texi2html 1.29
from ext2fs.texi on 3 August 1994 -->
<TITLE>Analysis of the Ext2fs structure - Superblock</TITLE>
<P>Go to the <A HREF="ext2fs_3.html">previous</A>, <A HREF="ext2fs_5.html">next</A> section.<P>
<H1><A NAME="SEC4" HREF="ext2fs_toc.html#SEC4">Superblock</A></H1>
<P>
In this section, the layout of a superblock is described. Here is the
official structure of an ext2fs superblock [include/linux/ext2_fs.h]:
<P>
<PRE>
struct ext2_super_block {
unsigned long s_inodes_count;
unsigned long s_blocks_count;
unsigned long s_r_blocks_count;
unsigned long s_free_blocks_count;
unsigned long s_free_inodes_count;
unsigned long s_first_data_block;
unsigned long s_log_block_size;
long s_log_frag_size;
unsigned long s_blocks_per_group;
unsigned long s_frags_per_group;
unsigned long s_inodes_per_group;
unsigned long s_mtime;
unsigned long s_wtime;
unsigned short s_mnt_count;
short s_max_mnt_count;
unsigned short s_magic;
unsigned short s_state;
unsigned short s_errors;
unsigned short s_pad;
unsigned long s_lastcheck;
unsigned long s_checkinterval;
unsigned long s_reserved[238];
};
</PRE>
<P>
<DL COMPACT>
<DT><CODE>s_inodes_count</CODE>
<DD>the total number of inodes on the fs.
<P>
<DT><CODE>s_blocks_count</CODE>
<DD>the total number of blocks on the fs.
<P>
<DT><CODE>s_r_blocks_count</CODE>
<DD>the total number of blocks reserved for the exclusive use of the
superuser.
<P>
<DT><CODE>s_free_blocks_count</CODE>
<DD>the total number of free blocks on the fs.
<P>
<DT><CODE>s_free_inodes_count</CODE>
<DD>the total number of free inodes on the fs.
<P>
<DT><CODE>s_first_data_block</CODE>
<DD>the position on the fs of the first data block. Usually, this is block
number 1 for fs containing 1024 bytes blocks and is number 0 for other
fs.
<P>
<DT><CODE>s_log_block_size</CODE>
<DD>used to compute the logical block size in bytes. The logical block size
is in fact <CODE>1024 &#60;&#60; s_log_block_size</CODE>.
<P>
<DT><CODE>s_log_frag_size</CODE>
<DD>used to compute the logical fragment size. The logical fragment size is
in fact <CODE>1024 &#60;&#60; s_log_frag_size</CODE> if <CODE>s_log_frag_size</CODE> is positive
and <CODE>1024 &#62;&#62; -s_log_frag_size</CODE> if <CODE>s_log_frag_size</CODE> is negative.
<P>
<DT><CODE>s_blocks_per_group</CODE>
<DD>the total number of blocks contained in a group.
<P>
<DT><CODE>s_frags_per_group</CODE>
<DD>the total number of fragments contained in a group.
<P>
<DT><CODE>s_inodes_per_group</CODE>
<DD>the total number of inodes contained in a group.
<P>
<DT><CODE>s_mtime</CODE>
<DD>the time at which the last mount of the fs was performed.
<P>
<DT><CODE>s_wtime</CODE>
<DD>the time at which the last write of the superblock on the fs was performed.
<P>
<DT><CODE>s_mnt_count</CODE>
<DD>the number of time the fs has been mounted in read-write mode without having
been checked.
<P>
<DT><CODE>s_max_mnt_count</CODE>
<DD>the maximum number of time the fs may be mounted in read-write mode before a
check must be done.
<P>
<DT><CODE>s_magic</CODE>
<DD>a magic number that permits the identification of the file system. It is
<CODE>0xEF53</CODE> for a normal ext2fs and <CODE>0xEF51</CODE> for versions of
ext2fs prior to 0.2b.
<P>
<DT><CODE>s_state</CODE>
<DD>the state of the file system. It contains an or'ed value of EXT2_VALID_FS
(0x0001) which means: unmounted cleanly; and EXT2_ERROR_FS (0x0002) which
means: errors detected by the kernel code.
<P>
<DT><CODE>s_errors</CODE>
<DD>indicates what operation to perform when an error occurs. See section <A HREF="ext2fs_10.html#SEC10">Error Handling</A>
<P>
<DT><CODE>s_pad</CODE>
<DD>unused.
<P>
<DT><CODE>s_lastcheck</CODE>
<DD>the time of the last check performed on the fs.
<P>
<DT><CODE>s_checkinterval</CODE>
<DD>the maximum possible time between checks on the fs.
<P>
<DT><CODE>s_reserved</CODE>
<DD>unused.
</DL>
<A NAME="IDX19"></A>
<P>
Times are measured in seconds since 00:00:00 GMT, January 1, 1970.
<P>
Once the superblock is read in memory, the ext2fs kernel code calculates
some other information and keeps them in another structure. This structure
has the following layout:
<P>
<PRE>
struct ext2_sb_info {
unsigned long s_frag_size;
unsigned long s_frags_per_block;
unsigned long s_inodes_per_block;
unsigned long s_frags_per_group;
unsigned long s_blocks_per_group;
unsigned long s_inodes_per_group;
unsigned long s_itb_per_group;
unsigned long s_desc_per_block;
unsigned long s_groups_count;
struct buffer_head * s_sbh;
struct ext2_super_block * s_es;
struct buffer_head * s_group_desc[EXT2_MAX_GROUP_DESC];
unsigned short s_loaded_inode_bitmaps;
unsigned short s_loaded_block_bitmaps;
unsigned long s_inode_bitmap_number[EXT2_MAX_GROUP_LOADED];
struct buffer_head * s_inode_bitmap[EXT2_MAX_GROUP_LOADED];
unsigned long s_block_bitmap_number[EXT2_MAX_GROUP_LOADED];
struct buffer_head * s_block_bitmap[EXT2_MAX_GROUP_LOADED];
int s_rename_lock;
struct wait_queue * s_rename_wait;
unsigned long s_mount_opt;
unsigned short s_mount_state;
};
</PRE>
<P>
<DL COMPACT>
<DT><CODE>s_frag_size</CODE>
<DD>fragment size in bytes.
<P>
<DT><CODE>s_frags_per_block</CODE>
<DD>number of fragments in a block.
<P>
<DT><CODE>s_inodes_per_block</CODE>
<DD>number of inodes in a block of the inode table.
<P>
<DT><CODE>s_frags_per_group</CODE>
<DD>number of fragments in a group.
<P>
<DT><CODE>s_blocks_per_group</CODE>
<DD>number of blocks in a group.
<P>
<DT><CODE>s_inodes_per_group</CODE>
<DD>number of inodes in a group.
<P>
<DT><CODE>s_itb_per_group</CODE>
<DD>number of inode table blocks per group.
<P>
<DT><CODE>s_desc_per_block</CODE>
<DD>number of group descriptors per block.
<P>
<DT><CODE>s_groups_count</CODE>
<DD>number of groups.
<P>
<DT><CODE>s_sbh</CODE>
<DD>the buffer containing the disk superblock in memory.
<P>
<DT><CODE>s_es</CODE>
<DD>pointer to the superblock in the buffer.
<P>
<DT><CODE>s_group_desc</CODE>
<DD>pointers to the buffers containing the group descriptors.
<P>
<DT><CODE>s_loaded_inode_bitmaps</CODE>
<DD>number of inodes bitmap cache entries used.
<P>
<DT><CODE>s_loaded_block_bitmaps</CODE>
<DD>number of blocks bitmap cache entries used.
<P>
<DT><CODE>s_inode_bitmap_number</CODE>
<DD>indicates to which group the inodes bitmap in the buffers belong.
<P>
<DT><CODE>s_inode_bitmap</CODE>
<DD>inode bitmap cache.
<P>
<DT><CODE>s_block_bitmap_number</CODE>
<DD>indicates to which group the blocks bitmap in the buffers belong.
<P>
<DT><CODE>s_block_bitmap</CODE>
<DD>block bitmap cache.
<P>
<DT><CODE>s_rename_lock</CODE>
<DD>lock used to avoid two simultaneous rename operations on a fs.
<P>
<DT><CODE>s_rename_wait</CODE>
<DD>wait queue used to wait for the completion of a rename operation in progress.
<P>
<DT><CODE>s_mount_opt</CODE>
<DD>the mounting options specified by the administrator.
<P>
<DT><CODE>s_mount_state</CODE>
<DD></DL>
<P>
Most of those values are computed from the superblock on disk.
<A NAME="IDX20"></A>
<A NAME="IDX21"></A>
<P>
Linux ext2fs manager caches access to the inodes and blocks
bitmaps. This cache is a list of buffers ordered from the most recently
used to the last recently used buffer. Managers should use the same kind
of bitmap caching or other similar method of improving access time to
disk.
<P>
<P>Go to the <A HREF="ext2fs_3.html">previous</A>, <A HREF="ext2fs_5.html">next</A> section.<P>

53
study/sabre/os/files/FileSystems/ext2fs/ext2fs_5.html Normal file
View File

@@ -0,0 +1,53 @@
<!-- X-URL: http://step.polymtl.ca/~ldd/ext2fs/ext2fs_5.html -->
<!-- This HTML file has been created by texi2html 1.29
from ext2fs.texi on 3 August 1994 -->
<TITLE>Analysis of the Ext2fs structure - Group Descriptors</TITLE>
<P>Go to the <A HREF="ext2fs_4.html">previous</A>, <A HREF="ext2fs_6.html">next</A> section.<P>
<H1><A NAME="SEC5" HREF="ext2fs_toc.html#SEC5">Group Descriptors</A></H1>
<P>
On disk, the group descriptors immediately follow the superblock and
each descriptor has the following layout:
<P>
<PRE>
struct ext2_group_desc
{
unsigned long bg_block_bitmap;
unsigned long bg_inode_bitmap;
unsigned long bg_inode_table;
unsigned short bg_free_blocks_count;
unsigned short bg_free_inodes_count;
unsigned short bg_used_dirs_count;
unsigned short bg_pad;
unsigned long bg_reserved[3];
};
</PRE>
<P>
<DL COMPACT>
<DT><CODE>bg_block_bitmap</CODE>
<DD>points to the blocks bitmap block for the group.
<P>
<DT><CODE>bg_inode_bitmap</CODE>
<DD>points to the inodes bitmap block for the group.
<P>
<DT><CODE>bg_inode_table</CODE>
<DD>points to the inodes table first block.
<P>
<DT><CODE>bg_free_blocks_count</CODE>
<DD>number of free blocks in the group.
<P>
<DT><CODE>bg_free_inodes_count</CODE>
<DD>number of free inodes in the group.
<P>
<DT><CODE>bg_used_dirs_count</CODE>
<DD>number of inodes allocated to directories in the group.
<P>
<DT><CODE>bg_pad</CODE>
<DD>padding.
</DL>
<P>
The information in a group descriptor pertains only to the group it is
actually describing.
<P>
<P>Go to the <A HREF="ext2fs_4.html">previous</A>, <A HREF="ext2fs_6.html">next</A> section.<P>

38
study/sabre/os/files/FileSystems/ext2fs/ext2fs_6.html Normal file
View File

@@ -0,0 +1,38 @@
<!-- X-URL: http://step.polymtl.ca/~ldd/ext2fs/ext2fs_6.html -->
<!-- This HTML file has been created by texi2html 1.29
from ext2fs.texi on 3 August 1994 -->
<TITLE>Analysis of the Ext2fs structure - Bitmaps</TITLE>
<P>Go to the <A HREF="ext2fs_5.html">previous</A>, <A HREF="ext2fs_7.html">next</A> section.<P>
<A NAME="IDX22"></A>
<H1><A NAME="SEC6" HREF="ext2fs_toc.html#SEC6">Bitmaps</A></H1>
<P>
The ext2 file system uses bitmaps to keep track of allocated blocks
and inodes.
<A NAME="IDX23"></A>
<A NAME="IDX24"></A>
<P>
The blocks bitmap of each group refers to blocks ranging from the first
block in the group to the last block in the group. To access the bit of
a precise block, we first have to look for the group the block belongs
to and then look for the bit of this block in the blocks bitmap
contained in the group. It it very important to note that the blocks
bitmap refer in fact to the smallest allocation unit supported by the
file system: fragments. Since the block size is always a multiple of
fragment size, when the file system manager allocates a block, it
actually allocates a multiple number of fragments. This use of the
blocks bitmap permits to the file system manager to allocate and
deallocate space on a fragment basis.
<A NAME="IDX25"></A>
<A NAME="IDX26"></A>
<P>
The inode bitmap of each group refer to inodes ranging from the first
inode of the group to the last inode of the group. To access the bit of
a precise inode, we first have to look for the group the inode belongs
to and then look for the bit of this inode in the inode bitmap contained
in the group. To obtain the inode information from the inode table, the
process is the same, except that the final search is in the inode table
of the group instead of the inode bitmap.
<P>
<P>Go to the <A HREF="ext2fs_5.html">previous</A>, <A HREF="ext2fs_7.html">next</A> section.<P>

180
study/sabre/os/files/FileSystems/ext2fs/ext2fs_7.html Normal file
View File

@@ -0,0 +1,180 @@
<!-- X-URL: http://step.polymtl.ca/~ldd/ext2fs/ext2fs_7.html -->
<!-- This HTML file has been created by texi2html 1.29
from ext2fs.texi on 3 August 1994 -->
<TITLE>Analysis of the Ext2fs structure - Inodes</TITLE>
<P>Go to the <A HREF="ext2fs_6.html">previous</A>, <A HREF="ext2fs_8.html">next</A> section.<P>
<A NAME="IDX27"></A>
<H1><A NAME="SEC7" HREF="ext2fs_toc.html#SEC7">Inodes</A></H1>
<A NAME="IDX28"></A>
<A NAME="IDX29"></A>
<A NAME="IDX30"></A>
<A NAME="IDX31"></A>
<A NAME="IDX32"></A>
<A NAME="IDX33"></A>
<P>
An inode uniquely describes a file. Here's what an inode looks like on
disk:
<P>
<PRE>
struct ext2_inode {
unsigned short i_mode;
unsigned short i_uid;
unsigned long i_size;
unsigned long i_atime;
unsigned long i_ctime;
unsigned long i_mtime;
unsigned long i_dtime;
unsigned short i_gid;
unsigned short i_links_count;
unsigned long i_blocks;
unsigned long i_flags;
unsigned long i_reserved1;
unsigned long i_block[EXT2_N_BLOCKS];
unsigned long i_version;
unsigned long i_file_acl;
unsigned long i_dir_acl;
unsigned long i_faddr;
unsigned char i_frag;
unsigned char i_fsize;
unsigned short i_pad1;
unsigned long i_reserved2[2];
};
</PRE>
<P>
<DL COMPACT>
<DT><CODE>i_mode</CODE>
<DD>type of file (character, block, link, etc.) and access rights on the
file.
<P>
<DT><CODE>i_uid</CODE>
<DD>uid of the owner of the file.
<P>
<DT><CODE>i_size</CODE>
<DD>logical size in bytes.
<P>
<DT><CODE>i_atime</CODE>
<DD>last time the file was accessed.
<P>
<DT><CODE>i_ctime</CODE>
<DD>last time the inode information of the file was changed.
<P>
<DT><CODE>i_mtime</CODE>
<DD>last time the file content was modified.
<P>
<DT><CODE>i_dtime</CODE>
<DD>when this file was deleted.
<P>
<DT><CODE>i_gid</CODE>
<DD>gid of the file.
<P>
<DT><CODE>i_links_count</CODE>
<DD>number of links pointing to this file.
<P>
<DT><CODE>i_blocks</CODE>
<DD>number of blocks allocated to this file counted in 512 bytes units.
<P>
<DT><CODE>i_flags</CODE>
<DD>flags (see below).
<P>
<DT><CODE>i_reserved1</CODE>
<DD>reserved.
<P>
<DT><CODE>i_block</CODE>
<DD>pointers to blocks (see below).
<P>
<DT><CODE>i_version</CODE>
<DD>version of the file (used by NFS).
<P>
<DT><CODE>i_file_acl</CODE>
<DD>control access list of the file (not used yet).
<P>
<DT><CODE>i_dir_acl</CODE>
<DD>control access list of the directory (not used yet).
<P>
<DT><CODE>i_faddr</CODE>
<DD>block where the fragment of the file resides.
<P>
<DT><CODE>i_frag</CODE>
<DD>number of the fragment in the block.
<P>
<DT><CODE>i_size</CODE>
<DD>size of the fragment.
<P>
<DT><CODE>i_pad1</CODE>
<DD>padding.
<P>
<DT><CODE>i_reserved2</CODE>
<DD>reserved.
</DL>
<P>
As you can see, the inode contains, <CODE>EXT2_N_BLOCKS</CODE> (15 in ext2fs
0.5) pointers to block. Of theses pointers, the first
<CODE>EXT2_NDIR_BLOCKS</CODE> (12) are direct pointers to data. The following entry
points to a block of pointers to data (indirect). The following entry
points to a block of pointers to blocks of pointers to data (double
indirection). The following entry points to a block of pointers to a
block of pointers to a block of pointers to data (triple indirection).
<P>
The inode flags may take one or more of the following or'ed values:
<P>
<DL COMPACT>
<DT><CODE>EXT2_SECRM_FL 0x0001</CODE>
<DD>secure deletion. This usually means that when this flag is set and we
delete the file, random data is written in the blocks previously allocated
to the file.
<P>
<DT><CODE>EXT2_UNRM_FL 0x0002</CODE>
<DD>undelete. When this flag is set and the file is being deleted, the file
system code must store enough information to ensure the undeletion of
the file (to a certain extent).
<P>
<DT><CODE>EXT2_COMPR_FL 0x0004</CODE>
<DD>compress file. The content of the file is compressed, the file system
code must use compression/decompression algorithms when accessing the
data of this file.
<P>
<DT><CODE>EXT2_SYNC_FL 0x0008</CODE>
<DD>synchronous updates. The disk representation of this file must be kept
in sync with it's in core representation. Asynchronous I/O on this kind
of file is not possible. The synchronous updates only apply to the inode
itself and to the indirect blocks. Data blocks are always written
asynchronously on the disk.
</DL>
<A NAME="IDX34"></A>
<A NAME="IDX35"></A>
<A NAME="IDX36"></A>
<A NAME="IDX37"></A>
<A NAME="IDX38"></A>
<A NAME="IDX39"></A>
<A NAME="IDX40"></A>
<A NAME="IDX41"></A>
<A NAME="IDX42"></A>
<P>
Some inodes have a special meaning:
<P>
<DL COMPACT>
<DT><CODE>EXT2_BAD_INO 1</CODE>
<DD>a file containing the list of bad blocks on the file system.
<P>
<DT><CODE>EXT2_ROOT_INO 2</CODE>
<DD>the root directory of the file system.
<P>
<DT><CODE>EXT2_ACL_IDX_INO 3</CODE>
<DD>ACL inode.
<P>
<DT><CODE>EXT2_ACL_DATA_INO 4</CODE>
<DD>ACL inode.
<P>
<DT><CODE>EXT2_BOOT_LOADER_INO 5</CODE>
<DD>the file containing the boot loader. (Not used yet it seems.)
<P>
<DT><CODE>EXT2_UNDEL_DIR_INO 6</CODE>
<DD>the undelete directory of the system.
<P>
<DT><CODE>EXT2_FIRST_INO 11</CODE>
<DD>this is the first inode that does not have a special meaning.
</DL>
<P>
<P>Go to the <A HREF="ext2fs_6.html">previous</A>, <A HREF="ext2fs_8.html">next</A> section.<P>

50
study/sabre/os/files/FileSystems/ext2fs/ext2fs_8.html Normal file
View File

@@ -0,0 +1,50 @@
<!-- X-URL: http://step.polymtl.ca/~ldd/ext2fs/ext2fs_8.html -->
<!-- This HTML file has been created by texi2html 1.29
from ext2fs.texi on 3 August 1994 -->
<TITLE>Analysis of the Ext2fs structure - Directories</TITLE>
<P>Go to the <A HREF="ext2fs_7.html">previous</A>, <A HREF="ext2fs_9.html">next</A> section.<P>
<A NAME="IDX43"></A>
<H1><A NAME="SEC8" HREF="ext2fs_toc.html#SEC8">Directories</A></H1>
<A NAME="IDX44"></A>
<P>
Directories are special files that are used to create access path to
the files on disk. It is very important to understand that an inode may
have many access paths. Since the directories are essential part of the
file system, they have a specific structure. A directory file is a list
of entries of the following format:
<P>
<PRE>
struct ext2_dir_entry {
unsigned long inode;
unsigned short rec_len;
unsigned short name_len;
char name[EXT2_NAME_LEN];
};
</PRE>
<P>
<DL COMPACT>
<DT><CODE>inode</CODE>
<DD>points to the inode of the file.
<P>
<DT><CODE>rec_len</CODE>
<DD>length of the entry record.
<P>
<DT><CODE>name_len</CODE>
<DD>length of the file name.
<P>
<DT><CODE>name</CODE>
<DD>name of the file. This name may have a maximum length of
<CODE>EXT2_NAME_LEN</CODE> bytes (255 bytes as of version 0.5).
</DL>
<A NAME="IDX45"></A>
<A NAME="IDX46"></A>
<A NAME="IDX47"></A>
<P>
There is such an entry in the directory file for each file in the
directory. Since ext2fs is a Unix file system the first two entries in
the directory are file <SAMP>`.'</SAMP> and <SAMP>`..'</SAMP> which points to the
current directory and the parent directory respectively.
<P>
<P>Go to the <A HREF="ext2fs_7.html">previous</A>, <A HREF="ext2fs_9.html">next</A> section.<P>

39
study/sabre/os/files/FileSystems/ext2fs/ext2fs_9.html Normal file
View File

@@ -0,0 +1,39 @@
<!-- X-URL: http://step.polymtl.ca/~ldd/ext2fs/ext2fs_9.html -->
<!-- This HTML file has been created by texi2html 1.29
from ext2fs.texi on 3 August 1994 -->
<TITLE>Analysis of the Ext2fs structure - Allocation algorithms</TITLE>
<P>Go to the <A HREF="ext2fs_8.html">previous</A>, <A HREF="ext2fs_10.html">next</A> section.<P>
<H1><A NAME="SEC9" HREF="ext2fs_toc.html#SEC9">Allocation algorithms</A></H1>
<P>
Here are the allocation algorithms that ext2 file system managers
<STRONG>must</STRONG> use. We are adamant on this point. Nowadays, many users
use more than one operating system on the same computer. If more than
one operating system use the same ext2 partition, they have to use the
same allocation algorithms. If they do otherwise, what will happen is
that one file system manager will undo the work of the other file system
manager. It is useless to have a manager that uses highly efficient
allocation algorithms if the other one does not bother with allocation
and uses quick and dirty algorithms.
<P>
Here are the rules used to allocate new inodes:
<P>
<UL>
<LI>the inode for a new file is allocated in the same group of the
inode of its parent directory.
<P>
<LI>inodes are allocated equally between groups.
</UL>
<P>
Here are the rules used to allocate new blocks:
<P>
<UL>
<LI>a new block is allocated in the same group as its inode.
<P>
<LI>allocate consecutive sequences of blocks.
</UL>
<P>
Of course, it may be sometimes impossible to abide by those rules. In
this case, the manager may allocate the block or inode anywhere.
<P>Go to the <A HREF="ext2fs_8.html">previous</A>, <A HREF="ext2fs_10.html">next</A> section.<P>

29
study/sabre/os/files/FileSystems/ext2fs/index.html Normal file
View File

@@ -0,0 +1,29 @@
<!-- X-URL: http://step.polymtl.ca/~ldd/ext2fs/ext2fs_toc.html -->
<!-- This HTML file has been created by texi2html 1.29
from ext2fs.texi on 3 August 1994 -->
<TITLE>Analysis of the Ext2fs structure - Table of Contents</TITLE>
<H1>Analysis of the Ext2fs structure</H1>
<ADDRESS>Louis-Dominique Dubeau</ADDRESS>
<P>
<UL>
<LI><A NAME="SEC1" HREF="ext2fs_1.html#SEC1">Introduction</A>
<LI><A NAME="SEC2" HREF="ext2fs_2.html#SEC2">Blocks and Fragments</A>
<LI><A NAME="SEC3" HREF="ext2fs_3.html#SEC3">Groups</A>
<LI><A NAME="SEC4" HREF="ext2fs_4.html#SEC4">Superblock</A>
<LI><A NAME="SEC5" HREF="ext2fs_5.html#SEC5">Group Descriptors</A>
<LI><A NAME="SEC6" HREF="ext2fs_6.html#SEC6">Bitmaps</A>
<LI><A NAME="SEC7" HREF="ext2fs_7.html#SEC7">Inodes</A>
<LI><A NAME="SEC8" HREF="ext2fs_8.html#SEC8">Directories</A>
<LI><A NAME="SEC9" HREF="ext2fs_9.html#SEC9">Allocation algorithms</A>
<LI><A NAME="SEC10" HREF="ext2fs_10.html#SEC10">Error Handling</A>
<LI><A NAME="SEC11" HREF="ext2fs_11.html#SEC11">Formulae</A>
<LI><A NAME="SEC12" HREF="ext2fs_12.html#SEC12">Invariants</A>
<UL>
<LI><A NAME="SEC13" HREF="ext2fs_13.html#SEC13">File Invariants</A>
<LI><A NAME="SEC14" HREF="ext2fs_14.html#SEC14">File System Invariants</A>
</UL>
<LI><A NAME="SEC15" HREF="ext2fs_15.html#SEC15">References</A>
<LI><A NAME="SEC16" HREF="ext2fs_16.html#SEC16">Concept Index</A>
</UL>