Monday, April 6, 2020
File-System Implementation
File-System
Implementation
File systems store several important data structures on the disk:
·
A boot-control block,
( per volume ) or the boot block in UNIX or the partition
boot sector in Windows contains information about how to boot the
system off of this disk. This will generally be the first sector of the volume
if there is a bootable system loaded on that volume, or the block will be left
vacant otherwise.
·
A volume control
block, ( per volume ) or the master file table in
UNIX or the superblock in Windows, which contains information
such as the partition table, number of blocks on each filesystem, and pointers
to free blocks and free FCB blocks.
·
A directory structure ( per file
system ), containing file names and pointers to corresponding FCBs. UNIX uses
inode numbers, and NTFS uses a master file table.
·
The File Control Block,
FCB, ( per file ) containing details about ownership, size,
permissions, dates, etc. UNIX stores this information in inodes, and NTFS in
the master file table as a relational database structure.
There are also several key data structures stored in memory:
·
An in-memory mount table.
·
An in-memory directory cache of
recently accessed directory information.
·
A system-wide open file table, containing a copy of the FCB for every currently open file in the
system, as well as some other related information.
·
A per-process open file
table, containing a pointer to the system open file
table as well as some other information.
Some of the interactions of file system components when files are created
and/or used:
·
When a new file is created, a new
FCB is allocated and filled out with important information regarding the new
file. The appropriate directory is modified with the new file name and FCB
information.
·
When a file is accessed during a
program, the open( ) system call reads in the FCB information from disk, and
stores it in the system-wide open file table. An entry is added to the
per-process open file table referencing the system-wide table, and an index
into the per-process table is returned by the open( ) system call. UNIX refers
to this index as a file descriptor, and Windows refers to it as
a file handle.
·
If another process already has a
file open when a new request comes in for the same file, and it is sharable,
then a counter in the system-wide table is incremented and the per-process
table is adjusted to point to the existing entry in the system-wide table.
·
When a file is closed, the
per-process table entry is freed, and the counter in the system-wide table is
decremented. If that counter reaches zero, then the system wide table is also
freed. Any data currently stored in memory cache for this file is written out
to disk if necessary.
Partitions and Mounting
·
Physical disks are commonly
divided into smaller units called partitions. They can also be combined into
larger units, but that is most commonly done for RAID installations and is left
for later chapters.
·
Partitions can either be used as
raw devices ( with no structure imposed upon them ), or they can be formatted
to hold a filesystem ( i.e. populated with FCBs and initial directory
structures as appropriate. ) Raw partitions are generally used for swap space,
and may also be used for certain programs such as databases that choose to
manage their own disk storage system. Partitions containing filesystems can
generally only be accessed using the file system structure by ordinary users,
but can often be accessed as a raw device also by root.
·
The boot block is accessed as
part of a raw partition, by the boot program prior to any operating system
being loaded. Modern boot programs understand multiple OSes and filesystem
formats, and can give the user a choice of which of several available systems
to boot.
·
The root partition contains
the OS kernel and at least the key portions of the OS needed to complete the
boot process. At boot time the root partition is mounted, and control is
transferred from the boot program to the kernel found there. ( Older systems
required that the root partition lie completely within the first 1024 cylinders
of the disk, because that was as far as the boot program could reach. Once the
kernel had control, then it could access partitions beyond the 1024 cylinder
boundary. )
·
Continuing with the boot process,
additional filesystems get mounted, adding their information into the appropriate
mount table structure. As a part of the mounting process the file systems may
be checked for errors or inconsistencies, either because they are flagged as
not having been closed properly the last time they were used, or just for
general principals. Filesystems may be mounted either automatically or
manually. In UNIX a mount point is indicated by setting a flag in the in-memory
copy of the inode, so all future references to that inode get re-directed to
the root directory of the mounted filesystem.
Virtual File Systems
·
Virtual File Systems, VFS, provide a common interface to multiple different filesystem types. In
addition, it provides for a unique identifier ( vnode ) for files across the
entire space, including across all filesystems of different types. ( UNIX
inodes are unique only across a single filesystem, and certainly do not carry
across networked file systems. )
·
The VFS in Linux is based upon
four key object types:
o
The inode object,
representing an individual file
o
The file object, representing an open file.
o
The superblock object, representing a filesystem.
o
The dentry object,
representing a directory entry.
·
Linux VFS provides a set of
common functionalities for each filesystem, using function pointers accessed
through a table. The same functionality is accessed through the same table
position for all filesystem types, though the actual functions pointed to by
the pointers may be filesystem-specific. Common operations provided include open(
), read( ), write( ), and mmap( ).
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment