Files
oldlinux-files/study/sabre/os/files/FileSystems/DesignGoalsHPFS/figs.html
2024-02-19 00:25:23 -05:00

157 lines
4.9 KiB
HTML

<html><head>
<title>HPFS: Illustrations</title>
</head>
<body>
<center>
<h1>HPFS: Illustrations</h1>
</center>
<center>
<a href="fig1.gif" name="fig1">
<img src="fig1.gif" alt="[Fig. 1]" border=0></a>
</center>
<p>
<b>FIGURE 1</b>:
This figure shows the overall structure of an HPFS volume. The most important
fixed objects in such a volume are the Bootblock the Super Block, and the
Spare Block. The remainder of the volume is divided into 8Mb bands. There is
a freespace bitmap for each band and the bitmaps are located between alternate
bands consequently, the maximum contiguous space which can be allocated to a
file is 16Mb.
<li><a href="hpfs_vol.html">HPFS Volume Structure</a>
<p>
<center>
<a href="fig2.gif" name="fig2">
<img src="fig2.gif" alt="[Fig. 2]" border=0></a>
</center>
<p>
<b>FIGURE 2</b>:
This figure shows the overall structure of an Fnode. The Fnode is the
fundamental object in an HPFS volume and is the first sector allocated to a
file or directory. it contains control and access history information used
by the file system, cached EAs and ACLs or pointers to same, a truncated
copy of the file or directory name (to aid disk repair programs, and an
allocation structure which defines the size and location of the file's storage.
<li><a href="fnodes.html">Files and FNodes</a>
<p>
<center>
<a href="fig3.gif" name="fig3">
<img src="fig3.gif" alt="[Fig. 3]" border=0></a>
</center>
<p>
<b>FIGURE 3</b>:
The simplest form of tracking for the sectors owned by a file is shown. The
Fnode s allocation structure points directly to as many as eight sector runs.
Each run pointer consists of a pair of 32-bit doublewords: a starting sector
number and a length !n sectors.
<li><a href="fnodes.html">Files and FNodes</a>
<p>
<center>
<a href="fig4.gif" name="fig4">
<img src="fig4.gif" alt="[Fig. 4]" border=0></a>
</center>
<p>
<b>FIGURE 4</b>:
This figure demonstrates the technique used to track the sectors owned by a
file with 9-480 sector runs. The allocation structure in the Fnode holds the
roots for a B+ Tree of allocation sectors. Each allocation sector can describe
as many as 40 sector runs. lf the file requires more than 480 sector runs,
additional intermediate levels are added to the B+ Tree, which increases the
number of possible sector runs by a factor of sixty for each new !evel.
<li><a href="fnodes.html">Files and FNodes</a>
<p>
<center>
<a href="fig5.gif" name="fig5">
<img src="fig5.gif" alt="[Fig. 5]" border=0></a>
</center>
<p>
<b>FIGURE 5</b>:
Here directories are anchored on an Fnode and are built up from 2Kb directory
blocks. The number of entries in a directory block varies because the length
of the entries depends on the filename. When a directory requires more than
one block the blocks are organized as a B-Tree. This allows a filename to be
located very quickly with a small number of disk accesses even when the
directory grows very large.
<li><a href="dirs.html">Directories</a>
<p>
<center>
<a href="fig6.gif" name="fig6">
<img src="fig6.gif" alt="[Fig. 6]" border=0></a>
</center>
<p>
<b>FIGURE 6</b>:
A simplified sketch of the relationship between an application program, the
OS/2 kernel, an installable file system, a disk drlver, and the physical disk
device. The applicatIon issues logical file requests to the OS/2 kernel by
calling the entry points for DosOpen, DosRead, DosWrlte, DosChgFilePtr, and
so on. The kernel passes these requests to the appropriate installable file
system for the volume holding the file. The installable file system translates
the logical file requests into requests for reads or writes of logical sectors
and calls a kernel File System Helper (FsHlp) to pass these requests to the
appropriate disk drlver. The disk driver transforms the logical sector
requests into requests for specific physical units, cylinders heads, and
sectors, and issues commands to the disk adapter to transfer data between the
disk and memory.
<li><a href="ifs.html">Installable File Systems</a>
<p>
<center>
<a href="figa.gif" name="figa">
<img src="figa.gif" alt="[Fig. A]" border=0></a>
</center>
<p>
<b>FIGURE A</b>:
To find a piece of data, the binary tree is traversed from the root until
the data is found or an empty subtree is encountered.
<li><a href="sum.html">Summary</a>
<p>
<center>
<a href="figb.gif" name="figb">
<img src="figb.gif" alt="[Fig. B]" border=0></a>
</center>
<p>
<b>FIGURE B</b>:
In a balanced B-Tree, data is stored in nodes, more than one data item can
be stored in a node, and all branches of the tree are the same length.
<li><a href="sum.html">Summary</a>
<p>
<center>
<a href="figc.gif" name="figc">
<img src="figc.gif" alt="[Fig. C]" border=0></a>
</center>
<p>
<b>FIGURE C</b>:
A B+ Tree has internal nodes that point to other nodes and external nodes
that contain actual data.
<li><a href="sum.html">Summary</a>
<p>
<hr>
<a href="hpfs.html">[HPFS Home]</a>
<hr>
<font size=-1>
Html'ed by <a href="http://www.seds.org/~spider/">Hartmut Frommert</a>
</font>
</body></html>