os-faq-fs.html

教导你怎么样写你自己的操作系统,并且列出来其它操作系统作为举例.

	  |---------------|
  SIZE-22 |     MINS      |
	  |---------------|
  SIZE-21 |    TICKS      |
	  |---------------|
  SIZE-20 | DIRECTORY NAME| Stored as a BCPL string <=30 chars
  	  |---------------|
  SIZE-4  | HASHCHAIN     | Next entry with same hash value
          |---------------|
  SIZE-3  |    PARENT     | back pointer to parent directory
          |---------------|
  SIZE-2  |      0        | Extension (always 0)
	  |---------------|
  SIZE-1  |  ST.USERDIR   | secondary type
	  +---------------+
</pre>
<p>
	User directory blocks have type T.SHORT and secondary type
ST.USERDIRECTORY. The six information words at the start of the block also
indicate the block's own key (this is, the block number) as a consistency
check and the size of the hash table. The 50 information words at the end
of the block contain the date and time of creation, the name of the
directory, a pointer to the next file or directory on the hash chain, and a
pointer to the directory above.
<p>
	To find a file or sub-directory, you must first apply a hash function to
its name. This has function yields and offset in the hash table, which is
the key of the first block on a chain linking those with the same hash
value (or 0, if there are none). AmigaDOS reads teh block with this key and
compares the name of the block with the required name. If the names do not
match, it reads the next block on the chain, and so on.

<p>
1.1.3 File Header Block
<pre>
	   +------------+
	0  |   T.SHORT  | Type
	   |------------|
	1  |   OWN KEY  | Header Key
	   |------------|
	2  | HIGHEST SEQ| Total number of data blocks in file
	   |------------|
	3  |  DATA SIZE | Number of data block slots used
	   |------------|
	4  | FIRST DATA | First data block
	   |------------|
	5  |  CHECKSUM  |
	   |------------|
	6  |		|
	   /            /
	   \            \
	   | DATA BLK 3 |
	   | DATA BLK 2 | List of data block keys
  SIZE-51  | DATA BLK 1 |
	   |------------|
  SIZE-50  |  Spare     |
	   |------------|
  SIZE-49  |   PROTECT  | Protection bits
	   |------------|
  SIZE-48  |  BYTESIZE  | Total size of file in bytes
	   |------------|
  SIZE-46  |		|
	   |  COMMENT   | Comment as a BCPL string
  SIZE-24  |            |
	   |------------|
  SIZE-23  |    DAYS    | Creation date and time
           |------------|
  SIZE-22  |    MINS    |
	   |------------|
  SIZE-21  |    TICKS   |
	   |------------|
  SIZE-20  | FILE NAME  | Stored as BCPL string <= 30 chars
	   |------------|
  SIZE-4   |  HASHCHAIN | Next entry with same hash value
	   |------------|
  SIZE-3   |   PARENT   | Back pointer to the parent directory
	   |------------|
  SIZE-2   |  EXTENSION | Zero pointer to the first extension 	  
           |------------| block
  SIZE-1   |  ST. FILE  | Secondary type
	   +------------+
</pre>
<p>
	Each terminal file starts with a file header block, which has type T.SHORT
and secondary type ST.FILE. The start and end of the block contain name,
time, and redundancy information similar to that in a directory block. The
body of the file consists of Data blocks with sequence numbers from 1
upwards. AmigaDOS stores the addresses of these blocks in consecutive words
downwards from offset size-51 in the block. In general, AmigaDOS does not
use all the space for this list and the last data block is not full.
<p>
1.1.4 File List Block
<p>
	If there are more blocks in the file than can be specified in the block
list, then the EXTENSION field is non-zero and points to another disk block
which contains a further data block list. The following figure explains the
structure of the file list block.
<pre>
	   +-------------+
	0  |   T. LIST   | Type
	   |-------------|
	1  |   OWN KEY   | Header Key
	   |-------------|
	2  | BLOCK COUNT | =number of data blocks in block list
	   |-------------|
	3  | DATA SIZE   | Same as above
	   |-------------|
	4  | FIRST DATA  | First Data Block
	   |-------------|
	5  |  CHECKSUM   |
	   |-------------|
	6  |             |
	   /             /
	   \             \
	   | BLOCK N+3   |
	   | BLOCK N+2   | Extended list of data block keys
  SIZE-51  | BLOCK N+1   |
	   |-------------|
  SIZE-50  |	  info   | (unused)
	   |-------------|
  SIZE-4   |     0       | Next in hash list (always 0)
	   |-------------|
  SIZE-3   |   PARENT    | File header block of this file
           |-------------|
  SIZE-2   | EXTENTSION  | Next extension block
	   |-------------|
  SIZE-1   |   ST. FILE  | Secondary type
	   +-------------+
</pre>
<p>
	There are as many file extension blocks as required to list the data
blocks that make up the file. The layout of the block is very similar to
that of a file header block, except that the type is different and the date
and filename fields are not used.
<p>
1.1.5 Data Block
<pre>
	   +-------------+
	0  |   T. DATA   | type
	   |-------------|
	1  |   HEADER    | header key
	   |-------------|
	2  |   SEQ NUM   | Sequence number
	   |-------------|
	3  |  DATA SIZE  |
	   |-------------|
	4  |  NEXT DATA  | next data block
	   |-------------|
	5  |  CHECKSUM   |
	   |-------------|
	6  |		 |
	   |             |
	   |             |
	   |             |
	   |    DATA     |
	   |             |
	   |             |
	   |             |
	   +-------------+
</pre>
<p>
	Data blocks contain only siz words of filing system information. These six
words refer to the following:
<ul>
	<li>type (T.DATA)
	<li>pointer to the file header block
	<li>sequence number of the data block
	<li>number of words of data
	<li>pointer to the next data block
	<li>checksum
</ul>	
<p>
	Normally, all data blocks except the last are full (that is, they have a
blocksize = blocksize-6). The last data block has a forward pointer of 0.
		</TD>
	</TR>
</TABLE>

<P>&nbsp;</P>
<TABLE border="0" width="100%">
	<TR>
		<TD><H2><A name="fs_ffs_bsd">Filesystems :: FFS (BSD)</A></H2>
		</TD>
	</TR>
	<TR>
		<TD>Not to be confused with the Amiga FFS, the BSD FFS is commonly used on hard disks
		for the FreeBSD, NetBSD etc, derivatives....
		<br><br>		
		more info...
		</TD>
	</TR>
</TABLE>

<P>&nbsp;</P>
<TABLE border="0" width="100%">
	<TR>
		<TD><H2><A name="fs_nfs">Filesystems :: NFS</A></H2>
		</TD>
	</TR>
	<TR>
		<TD>
NFS was invented by Sun Microsystems.  It became widespread largely because
it'a quite easy to implement.  In return for its simplicity, it tends to
give relatively poor performance and a nearly complete lack of safety.
These are both due largely to its connectionless nature.  When you request
data from a file, the server sends you the requested information, but does
NOT keep track of which clients have which files open.  To keep you from
seeing (terribly) out-of-date information from a file, the data you read
has an "expiration date".  If you refer to the data from more than, say, a
minute, it will expire and your client will request the data from the
server again, whether it's changed or not.  If you write data to the file,
you have no way of knowing whether somebody else has updated the
information between your reading and writing your data, so you may
overwrite things they've written with older data.  To ensure at least a
little bit of safety, the server is supposed to actually commit data you
write to disk before it returns to you.
<p>
IOW, NFS works pretty well for read-only access to things like executables
on a server.  For things like on-line databases, it's essentially a
disaster waiting  to happen (and it usually doesn't wait very long).
<p>
More recent versions of the NFS spec have cured most of these problems, but
support for these updates is still (years later) somewhat uneven.
		</TD>
	</TR>
</TABLE>

<P>&nbsp;</P>
<TABLE border="0" width="100%">
	<TR>
		<TD><H2><A name="fs_afs">Filesystems :: AFS</A></H2>
		</TD>
	</TR>
	<TR>
		<TD>AFS is the Andrew File System aka Advanced File System, and from
		memory is like a FTP filesystem / NFS type filesystem...
		<p>
AFS is similar to NFS to about the same degree that a tricycle is similar
to a fighter jet -- they're both typically one-person vehicles.  AFS is a
drastically more robust design than NFS, and is intended for MUCH larger
networks.  OTOH, it's also much more difficult to implement completely --
to the point that it's not likely to be of much interest to most hobbiests
and such writing a new OS.		
		</TD>
	</TR>
</TABLE>

<P>&nbsp;</P>
<table border="0" width="100%">
	<TR>
		<TD><H2><A name="fs_rfs">Filesystems :: RFS</A></H2>
		</TD>
	</TR>
	<TR>
		<TD>
RFS (Remote File System) was introduced in UNIX System V to compete with
NFS and such.  Unlike NFS, RFS is a connection-oriented system, so if, for
example, two different machines access a file on a server, they get about
the same semantics as if two processes on a single machine accessed the file.
<p>
Note that NFS and RFS are both built on top of some sort of local file
system, which determines things like inodes and such.
		</td>
	</tr>
</table>

<P>&nbsp;</P>
<TABLE border="0" width="100%">
	<TR>
		<TD><H2><A name="fs_xfs">Filesystems :: XFS</A></H2>
		</TD>
	</TR>
	<TR>
		<TD>XFS is Silicon Graphics &quot;A Next Generation Journalled 64-Bit
		Filesystem With Guaranteed Rate I/O&quot; filesystem designed for IRIX
		based systems.
		<p>XFS uses the standard inodes, bitmaps and blocks, and is compatable
		with EFS and NFS filesystems.</p>
		<p>According to the XFS white paper it has;
		<ul>
			<li>Scalable features and performance from small to truly huge data (petabytes)		
			<li>Huge numbers of files (millions) 
			<li>Exceptional performance: 500+ MBytes/second 
			<li>Designed with log/database (journal) technology as a fundamental part not just an extension to an existing filesystem 
			<li>Mission-critical reliability
		</ul>
		</p>
		</TD>
	</TR>
</TABLE>

</body>
</html>