SlideShare a Scribd company logo
Silberschatz, Galvin and Gagne ©2009
Operating System Concepts – 8th
Edition,
Chapter 11: File System
Implementation
11.2 Silberschatz, Galvin and Gagne ©2009
Operating System Concepts – 8th
Edition
Chapter 11: File System Implementation
 File-System Structure
 File-System Implementation
 Directory Implementation
 Allocation Methods
 Free-Space Management
 Efficiency and Performance
 Recovery
 Log-Structured File Systems
 NFS
 Example: WAFL File System
11.3 Silberschatz, Galvin and Gagne ©2009
Operating System Concepts – 8th
Edition
Objectives
 To describe the details of implementing local file systems and directory
structures
 To describe the implementation of remote file systems
 To discuss block allocation and free-block algorithms and trade-offs
11.4 Silberschatz, Galvin and Gagne ©2009
Operating System Concepts – 8th
Edition
File-System Structure
 File structure
 Logical storage unit
 Collection of related information
 File system resides on secondary storage (disks)
 File system organized into layers
 File control block – storage structure consisting of information about a file
11.5 Silberschatz, Galvin and Gagne ©2009
Operating System Concepts – 8th
Edition
Layered File System
11.6 Silberschatz, Galvin and Gagne ©2009
Operating System Concepts – 8th
Edition
A Typical File Control Block
11.7 Silberschatz, Galvin and Gagne ©2009
Operating System Concepts – 8th
Edition
In-Memory File System Structures
 The following figure illustrates the necessary file system structures provided
by the operating systems.
 Figure 12-3(a) refers to opening a file.
 Figure 12-3(b) refers to reading a file.
11.8 Silberschatz, Galvin and Gagne ©2009
Operating System Concepts – 8th
Edition
In-Memory File System Structures
11.9 Silberschatz, Galvin and Gagne ©2009
Operating System Concepts – 8th
Edition
Virtual File Systems
 Virtual File Systems (VFS) provide an object-oriented way of implementing
file systems.
 VFS allows the same system call interface (the API) to be used for different
types of file systems.
 The API is to the VFS interface, rather than any specific type of file system.
11.10 Silberschatz, Galvin and Gagne ©2009
Operating System Concepts – 8th
Edition
Schematic View of Virtual File System
11.11 Silberschatz, Galvin and Gagne ©2009
Operating System Concepts – 8th
Edition
Directory Implementation
 Linear list of file names with pointer to the data blocks.
 simple to program
 time-consuming to execute
 Hash Table – linear list with hash data structure.
 decreases directory search time
 collisions – situations where two file names hash to the same location
 fixed size
11.12 Silberschatz, Galvin and Gagne ©2009
Operating System Concepts – 8th
Edition
Allocation Methods
 An allocation method refers to how disk blocks are allocated for files:
 Contiguous allocation
 Linked allocation
 Indexed allocation
11.13 Silberschatz, Galvin and Gagne ©2009
Operating System Concepts – 8th
Edition
Contiguous Allocation
 Each file occupies a set of contiguous blocks on the disk
 Best-fit ,first-fit or worst-fit algorithm
 Directory entry contains starting block number and file size(in blocks)
 Good for sequential and random access
 Simple – only starting location (block #) and length (number of blocks)
are required.
 Disadvantage
 Disk will become fragment
 Difficult to grow file
 Advantages
 Easy to implement
 Excellent read performance
11.14 Silberschatz, Galvin and Gagne ©2009
Operating System Concepts – 8th
Edition
Contiguous Allocation
 Mapping from logical to physical
LA/512
Q
R
Block to be accessed = ! + starting address
Displacement into block = R
11.15 Silberschatz, Galvin and Gagne ©2009
Operating System Concepts – 8th
Edition
Contiguous Allocation of Disk Space
11.16 Silberschatz, Galvin and Gagne ©2009
Operating System Concepts – 8th
Edition
Extent-Based Systems
 Here, a contiguous chunk of space is allocated initially; then, if that amount
proves not to be large enough, another chunk of contiguous space, known
as an extent is added
 The location of a file's blocks is then recorded as a location and a block
count, plus a link to the first block of the next extent.
 Many newer file systems (I.e. Veritas File System) use a modified
contiguous allocation scheme
 Extent-based file systems allocate disk blocks in extents
 An extent is a contiguous block of disks
 Extents are allocated for file allocation
 A file consists of one or more extents.
11.17 Silberschatz, Galvin and Gagne ©2009
Operating System Concepts – 8th
Edition
Linked Allocation
 Each file is a linked list of disk blocks: blocks may be scattered anywhere on
the disk.
pointer
block =
11.18 Silberschatz, Galvin and Gagne ©2009
Operating System Concepts – 8th
Edition
Linked Allocation (Cont.)
 Simple – need only starting address
 Free-space management system – no waste of space
 No random access
 Mapping
Block to be accessed is the Qth block in the linked chain of
blocks representing the file.
Displacement into block = R + 1
File-allocation table (FAT) – disk-space allocation used by MS-DOS
and OS/2.
LA/511
Q
R
11.19 Silberschatz, Galvin and Gagne ©2009
Operating System Concepts – 8th
Edition
Linked Allocation
11.20 Silberschatz, Galvin and Gagne ©2009
Operating System Concepts – 8th
Edition
File-Allocation Table
An illustrative
example is the FAT
structure
shown in Figure 11.7
for a file consisting of
disk blocks 217, 618,
and 339.
11.21 Silberschatz, Galvin and Gagne ©2009
Operating System Concepts – 8th
Edition
Linked Allocation
 Advantages
 No external fragmentation
 File size can increase
 Disadvantages
 Large seek time .
 Random access difficult
 Overhead of pointers
11.22 Silberschatz, Galvin and Gagne ©2009
Operating System Concepts – 8th
Edition
Indexed Allocation
 Linked allocation solves the external-fragmentation and
size-declaration problems of contiguous allocation.
 However, in the absence of a FAT, linked allocation
cannot support efficient direct access, since the pointers
to the blocks are scattered with the blocks themselves all
over the disk and must be retrieved in order.
 Indexed Allocation solves this problem by bringing all the
pointers together into one location the index block.
11.23 Silberschatz, Galvin and Gagne ©2009
Operating System Concepts – 8th
Edition
Indexed Allocation
 Brings all pointers together into the index block.
 Logical view.
index table
11.24 Silberschatz, Galvin and Gagne ©2009
Operating System Concepts – 8th
Edition
Example of Indexed Allocation
11.25 Silberschatz, Galvin and Gagne ©2009
Operating System Concepts – 8th
Edition
Indexed Allocation (Cont.)
 Need index table
 Random access
 Dynamic access without external fragmentation, but have overhead
of index block.
 Mapping from logical to physical in a file of maximum size of 256K
words and block size of 512 words. We need only 1 block for index
table.
LA/512
Q
R
Q = displacement into index table
R = displacement into block
11.26 Silberschatz, Galvin and Gagne ©2009
Operating System Concepts – 8th
Edition
Indexed Allocation
 Every file must have an index block so it should be as small as possible. But
if it is too small, it will not be able to hold enough pointers for a large file and
a mechanism will have to be available to deal with this issue. Mechanisms
for this purpose include –
 Linked Scheme: An index block is normally one disk block. Thus, it can be
read and written directly by itself. To allow for large files, we may link
together several index blocks.
 Multilevel index: A variant of the linked representation is to use a first level
index block to point to a set of second – level index blocks.
 Combined scheme: Another alternative, used in the UFS, is to keep the
first, say, 15 pointers of the index block in the file’s inode.
11.27 Silberschatz, Galvin and Gagne ©2009
Operating System Concepts – 8th
Edition
Indexed Allocation – Mapping (Cont.)

outer-index
index table file
11.28 Silberschatz, Galvin and Gagne ©2009
Operating System Concepts – 8th
Edition
Combined Scheme: UNIX (4K bytes per block)
Unix inode
11.29 Silberschatz, Galvin and Gagne ©2009
Operating System Concepts – 8th
Edition
Free-Space Management
 Since disk space is limited, we should reuse the space from deleted files for
new files. To keep track of free disk space, the system maintains a free
space list.
 The free space list records all free disk blocks – those not allocated to some
file or directory. This free space list can be implemented as one of the
following:
 Bit vector – free space list is implemented as a bit map or a bit vector.
Each block is represented by one bit. If the block is free, bit is 1, if the block
is allocated, bit is 0.
11.30 Silberschatz, Galvin and Gagne ©2009
Operating System Concepts – 8th
Edition
Free-Space Management
 Bit vector (n blocks)
…
0 1 2 n-1
bit[i] =

0  block[i] free
1  block[i] occupied
Block number calculation
(number of bits per word) *
(number of 0-value words) +
offset of first 1 bit
The calculation of the block number is
(Number of bits per word) * (number of 0-value words) + offset of first 1 bit
11.31 Silberschatz, Galvin and Gagne ©2009
Operating System Concepts – 8th
Edition
Linked Free Space List on Disk
 Linked list – Another approach to free space management is to link
together all the free disk blocks keeping a pointer to the first free
block in a special location on the disk and caching it in memory. The
first block contains a pointer to the next free disk block.
 Grouping – A modification of the free list approach is to store the
addresses of n free blocks in the first free block.
 Counting – Another approach is to take advantage of the fact that
several contiguous blocks may be allocated or freed simultaneously
when space is allocated with the contiguous allocation algorithm or
clustering.
11.32 Silberschatz, Galvin and Gagne ©2009
Operating System Concepts – 8th
Edition
Linked Free Space List on Disk
11.33 Silberschatz, Galvin and Gagne ©2009
Operating System Concepts – 8th
Edition
Efficiency and Performance
 Efficiency dependent on:
 disk allocation and directory algorithms
 types of data kept in file’s directory entry
 Performance
 disk cache – separate section of main memory for frequently used
blocks
 free-behind and read-ahead – techniques to optimize sequential access
 improve PC performance by dedicating section of memory as virtual
disk, or RAM disk
11.34 Silberschatz, Galvin and Gagne ©2009
Operating System Concepts – 8th
Edition
Page Cache and Buffer cache
 Most disk controllers include local memory to form an on board
cache that is large enough to store entire tracks at a time. Once a
seek is performed, the track is read into the disk cache starting at
the sector under the disk head. The disk controller then transfers
any sector requests to OS. Some systems maintain a separate
section of main memory for a buffer cache where blocks are kept
under the assumption that they will be used again.
 Other systems cache file data using a page cache. The page cache
uses virtual memory techniques to cache file data as pages rather
than as a file system oriented blocks.
11.35 Silberschatz, Galvin and Gagne ©2009
Operating System Concepts – 8th
Edition
Page Cache
 A page cache caches pages rather than disk blocks using virtual memory
techniques
 Memory-mapped I/O uses a page cache
 Routine I/O through the file system uses the buffer (disk) cache
 This leads to the following figure
11.36 Silberschatz, Galvin and Gagne ©2009
Operating System Concepts – 8th
Edition
I/O Without a Unified Buffer Cache
11.37 Silberschatz, Galvin and Gagne ©2009
Operating System Concepts – 8th
Edition
Unified Buffer Cache
 A unified buffer cache uses the same page cache to cache both memory-
mapped pages and ordinary file system I/O
 . Several systems use page caching to cache both process pages and file
data. This is known as unified buffer cache.
11.38 Silberschatz, Galvin and Gagne ©2009
Operating System Concepts – 8th
Edition
I/O Using a Unified Buffer Cache
11.39 Silberschatz, Galvin and Gagne ©2009
Operating System Concepts – 8th
Edition
Recovery
 Files and directories are kept both in main memory and on disk, and care
must be taken to ensure that system failure does not result in loss of data or
in data inconsistency.
 Consistency checking – compares data in directory structure with data
blocks on disk, and tries to fix inconsistencies
 Use system programs to back up data from disk to another storage device
(floppy disk, magnetic tape, other magnetic disk, optical)
 Recover lost file or disk by restoring data from backup
11.40 Silberschatz, Galvin and Gagne ©2009
Operating System Concepts – 8th
Edition
Log Structured File Systems
 While all reads are impossible to be carried out
sequentially (since any file may be accessed at any point
of time), we can exploit the efficiency of sequential writes.
LFS keeps a small buffer of all writes in a
memory segment
 A log is simply a data structure which is written only at the
head (one could think of the entire disk as a log). Once
the log is full, it is written into an unused part of the disk in
a sequential manner. New data and metadata (inodes,
directories) are accumulated into the buffer cache and
written all at once in large blocks (such as segments of
0.5M or 1M).
11.41 Silberschatz, Galvin and Gagne ©2009
Operating System Concepts – 8th
Edition
Log Structured File Systems
 Log structured (or journaling) file systems record each update to
the file system as a transaction
 All transactions are written to a log
 A transaction is considered committed once it is written to the
log
 However, the file system may not yet be updated
 The transactions in the log are asynchronously written to the file
system
 When the file system is modified, the transaction is removed
from the log
 If the file system crashes, all remaining transactions in the log must
still be performed
11.42 Silberschatz, Galvin and Gagne ©2009
Operating System Concepts – 8th
Edition
The Sun Network File System (NFS)
 Network file systems are commonplace. They are typically integrated with
the overall directory structure and interface of the client system. NFS is a
good example of a widely used, well-implemented client-server network file
system.
 Here, we use it as an example to explore the implementation details of
network file systems.
 An implementation and a specification of a software system for accessing
remote files across LANs (or WANs)
 The implementation is part of the Solaris and SunOS operating systems
running on Sun workstations using an unreliable datagram protocol (UDP/IP
protocol and Ethernet
11.43 Silberschatz, Galvin and Gagne ©2009
Operating System Concepts – 8th
Edition
NFS (Cont.)
 Interconnected workstations viewed as a set of independent machines with
independent file systems, which allows sharing among these file systems in
a transparent manner
 A remote directory is mounted over a local file system directory
 The mounted directory looks like an integral subtree of the local file
system, replacing the subtree descending from the local directory
 Specification of the remote directory for the mount operation is
nontransparent; the host name of the remote directory has to be
provided
 Files in the remote directory can then be accessed in a transparent
manner
 Subject to access-rights accreditation, potentially any file system (or
directory within a file system), can be mounted remotely on top of any
local directory
11.44 Silberschatz, Galvin and Gagne ©2009
Operating System Concepts – 8th
Edition
NFS (Cont.)
 NFS is designed to operate in a heterogeneous environment of different
machines, operating systems, and network architectures; the NFS
specifications independent of these media
 This independence is achieved through the use of RPC primitives built on
top of an External Data Representation (XDR) protocol used between two
implementation-independent interfaces
 The NFS specification distinguishes between the services provided by a
mount mechanism and the actual remote-file-access services
11.45 Silberschatz, Galvin and Gagne ©2009
Operating System Concepts – 8th
Edition
However, from then on, users on machine Ml can access files in the remote
directory in a totally transparent manner. To illustrate file mounting, consider the
file system depicted in Figure 11.13,
where the triangles represent sub trees of directories that are of interest. The
figure shows three independent file systems of machines named U, S1, and
S2. At this point, on each machine, only the local files can be accessed. Figure
11.14(a) shows the effects of mounting S1: /usr/shared over U: /usr/local.
This figure depicts the view users on U have of their file system. Notice that
after the mount is complete, they can access any file within the dir1 directory
using the prefix /usr /local/ dir1. The original directory /usr /local on that
machine is no longer visible.
In Figure 11.14(b), we illustrate cascading mounts. The figure shows the
result of mounting S2: /usr /dir2 over U: /usr/local/dir1, which is already
remotely mounted from 51. Users can access files within dir2 on U using the prefix
/usr/local/dir1. If a shared file system is mounted over a user's home
directories on all machines in a network, the user can log into any workstation
and get his honce environment.
11.46 Silberschatz, Galvin and Gagne ©2009
Operating System Concepts – 8th
Edition
Three Independent File Systems
11.47 Silberschatz, Galvin and Gagne ©2009
Operating System Concepts – 8th
Edition
Mounting in NFS
Mounts Cascading mounts
11.48 Silberschatz, Galvin and Gagne ©2009
Operating System Concepts – 8th
Edition
NFS Mount Protocol
 Establishes initial logical connection between server and client
 Mount operation includes name of remote directory to be mounted and
name of server machine storing it
 Mount request is mapped to corresponding RPC and forwarded to
mount server running on server machine
 Export list – specifies local file systems that server exports for
mounting, along with names of machines that are permitted to
mount them
 Following a mount request that conforms to its export list, the server
returns a file handle—a key for further accesses
 File handle – a file-system identifier, and an inode number to identify
the mounted directory within the exported file system
 The mount operation changes only the user’s view and does not affect
the server side
11.49 Silberschatz, Galvin and Gagne ©2009
Operating System Concepts – 8th
Edition
NFS Protocol
 Provides a set of remote procedure calls for remote file operations. The
procedures support the following operations:
 searching for a file within a directory
 reading a set of directory entries
 manipulating links and directories
 accessing file attributes
 reading and writing files
 NFS servers are stateless; each request has to provide a full set of
arguments
(NFS V4 is just coming available – very different, stateful)
 Modified data must be committed to the server’s disk before results are
returned to the client (lose advantages of caching)
 The NFS protocol does not provide concurrency-control mechanisms
11.50 Silberschatz, Galvin and Gagne ©2009
Operating System Concepts – 8th
Edition
Three Major Layers of NFS Architecture
 UNIX file-system interface (based on the open, read, write, and close
calls, and file descriptors)
 Virtual File System (VFS) layer – distinguishes local files from remote ones,
and local files are further distinguished according to their file-system types
 The VFS activates file-system-specific operations to handle local
requests according to their file-system types
 Calls the NFS protocol procedures for remote requests
 NFS service layer – bottom layer of the architecture
 Implements the NFS protocol
11.51 Silberschatz, Galvin and Gagne ©2009
Operating System Concepts – 8th
Edition
Schematic View of NFS Architecture
11.52 Silberschatz, Galvin and Gagne ©2009
Operating System Concepts – 8th
Edition
Example: WAFL File System
 The WAFL file system from WAFL, the write-anywhere file layout, is a
powerful, elegant file system optimized for random writes.
 Used on Network Appliance “Filers” – distributed file system appliances
 “Write-anywhere file layout”
 Serves up NFS, CIFS, http, ftp
 Random I/O optimized, write optimized
 NVRAM for write caching
 Similar to Berkeley Fast File System, with extensive modifications
11.53 Silberschatz, Galvin and Gagne ©2009
Operating System Concepts – 8th
Edition
The WAFL File Layout
11.54 Silberschatz, Galvin and Gagne ©2009
Operating System Concepts – 8th
Edition
Snapshots in WAFL
11.55 Silberschatz, Galvin and Gagne ©2009
Operating System Concepts – 8th
Edition
11.02
Silberschatz, Galvin and Gagne ©2009
Operating System Concepts – 8th
Edition,
End of Chapter 11

More Related Content

PPTX
Ch11 file system implementation
PPT
11.file system implementation
PPTX
ch11 File System Implementation.pptx important rdbms topic
PPT
file system implementation in operating systems
PPTX
ch12-File-System Implementation (1).pptx
PPT
File_System_Fundamentals savitchAbsJavaPPT Java Programming Part 2
PPTX
Chapter 14 Computer Architecture
PPTX
File system interface ppt chapter 10 Operating systems
Ch11 file system implementation
11.file system implementation
ch11 File System Implementation.pptx important rdbms topic
file system implementation in operating systems
ch12-File-System Implementation (1).pptx
File_System_Fundamentals savitchAbsJavaPPT Java Programming Part 2
Chapter 14 Computer Architecture
File system interface ppt chapter 10 Operating systems

Similar to Operating systems presentation part 1 2025 (20)

PPT
operating system notes for II year IV semester students
PDF
ch10operating e systemss.pdf
PPT
ch11.ppt
PPT
FIle Management.ppt
PPT
Lecture10-File Systems-PAfgfgfgfgfgfgf.ppt
PPT
ch10.ppt
PPT
638241896796578949.PPTcfrdrservbvmnbmnbjh
PPT
Ch11 file system interface
PPT
PPT
Ch12 OS
 
PPT
Chapter 11 - File System Implementation
PPT
Ch11: File System Interface
PPTX
OS Module 4 Slides - File system (1).pptx
PPTX
Chapter 13 silbershatz operating systems
PPT
10.file system interface
PPT
Chapter 11 File-System Interface in os.ppt
PPTX
FILE Implementation Introduction imp .pptx
PPT
ch11.ppt
PPTX
File system implementation
operating system notes for II year IV semester students
ch10operating e systemss.pdf
ch11.ppt
FIle Management.ppt
Lecture10-File Systems-PAfgfgfgfgfgfgf.ppt
ch10.ppt
638241896796578949.PPTcfrdrservbvmnbmnbjh
Ch11 file system interface
Ch12 OS
 
Chapter 11 - File System Implementation
Ch11: File System Interface
OS Module 4 Slides - File system (1).pptx
Chapter 13 silbershatz operating systems
10.file system interface
Chapter 11 File-System Interface in os.ppt
FILE Implementation Introduction imp .pptx
ch11.ppt
File system implementation
Ad

Recently uploaded (20)

PDF
Computing-Curriculum for Schools in Ghana
PPTX
Introduction_to_Human_Anatomy_and_Physiology_for_B.Pharm.pptx
PPTX
Pharmacology of Heart Failure /Pharmacotherapy of CHF
PDF
Saundersa Comprehensive Review for the NCLEX-RN Examination.pdf
PDF
Physiotherapy_for_Respiratory_and_Cardiac_Problems WEBBER.pdf
PDF
Microbial disease of the cardiovascular and lymphatic systems
PDF
01-Introduction-to-Information-Management.pdf
PDF
Anesthesia in Laparoscopic Surgery in India
PDF
Complications of Minimal Access Surgery at WLH
PDF
Insiders guide to clinical Medicine.pdf
PPTX
Cell Types and Its function , kingdom of life
PPTX
Final Presentation General Medicine 03-08-2024.pptx
PPTX
school management -TNTEU- B.Ed., Semester II Unit 1.pptx
PDF
O5-L3 Freight Transport Ops (International) V1.pdf
PDF
Module 4: Burden of Disease Tutorial Slides S2 2025
PPTX
1st Inaugural Professorial Lecture held on 19th February 2020 (Governance and...
PDF
Chapter 2 Heredity, Prenatal Development, and Birth.pdf
PDF
BÀI TẬP BỔ TRỢ 4 KỸ NĂNG TIẾNG ANH 9 GLOBAL SUCCESS - CẢ NĂM - BÁM SÁT FORM Đ...
PDF
STATICS OF THE RIGID BODIES Hibbelers.pdf
PDF
ANTIBIOTICS.pptx.pdf………………… xxxxxxxxxxxxx
Computing-Curriculum for Schools in Ghana
Introduction_to_Human_Anatomy_and_Physiology_for_B.Pharm.pptx
Pharmacology of Heart Failure /Pharmacotherapy of CHF
Saundersa Comprehensive Review for the NCLEX-RN Examination.pdf
Physiotherapy_for_Respiratory_and_Cardiac_Problems WEBBER.pdf
Microbial disease of the cardiovascular and lymphatic systems
01-Introduction-to-Information-Management.pdf
Anesthesia in Laparoscopic Surgery in India
Complications of Minimal Access Surgery at WLH
Insiders guide to clinical Medicine.pdf
Cell Types and Its function , kingdom of life
Final Presentation General Medicine 03-08-2024.pptx
school management -TNTEU- B.Ed., Semester II Unit 1.pptx
O5-L3 Freight Transport Ops (International) V1.pdf
Module 4: Burden of Disease Tutorial Slides S2 2025
1st Inaugural Professorial Lecture held on 19th February 2020 (Governance and...
Chapter 2 Heredity, Prenatal Development, and Birth.pdf
BÀI TẬP BỔ TRỢ 4 KỸ NĂNG TIẾNG ANH 9 GLOBAL SUCCESS - CẢ NĂM - BÁM SÁT FORM Đ...
STATICS OF THE RIGID BODIES Hibbelers.pdf
ANTIBIOTICS.pptx.pdf………………… xxxxxxxxxxxxx
Ad

Operating systems presentation part 1 2025

  • 1. Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8th Edition, Chapter 11: File System Implementation
  • 2. 11.2 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8th Edition Chapter 11: File System Implementation  File-System Structure  File-System Implementation  Directory Implementation  Allocation Methods  Free-Space Management  Efficiency and Performance  Recovery  Log-Structured File Systems  NFS  Example: WAFL File System
  • 3. 11.3 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8th Edition Objectives  To describe the details of implementing local file systems and directory structures  To describe the implementation of remote file systems  To discuss block allocation and free-block algorithms and trade-offs
  • 4. 11.4 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8th Edition File-System Structure  File structure  Logical storage unit  Collection of related information  File system resides on secondary storage (disks)  File system organized into layers  File control block – storage structure consisting of information about a file
  • 5. 11.5 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8th Edition Layered File System
  • 6. 11.6 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8th Edition A Typical File Control Block
  • 7. 11.7 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8th Edition In-Memory File System Structures  The following figure illustrates the necessary file system structures provided by the operating systems.  Figure 12-3(a) refers to opening a file.  Figure 12-3(b) refers to reading a file.
  • 8. 11.8 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8th Edition In-Memory File System Structures
  • 9. 11.9 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8th Edition Virtual File Systems  Virtual File Systems (VFS) provide an object-oriented way of implementing file systems.  VFS allows the same system call interface (the API) to be used for different types of file systems.  The API is to the VFS interface, rather than any specific type of file system.
  • 10. 11.10 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8th Edition Schematic View of Virtual File System
  • 11. 11.11 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8th Edition Directory Implementation  Linear list of file names with pointer to the data blocks.  simple to program  time-consuming to execute  Hash Table – linear list with hash data structure.  decreases directory search time  collisions – situations where two file names hash to the same location  fixed size
  • 12. 11.12 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8th Edition Allocation Methods  An allocation method refers to how disk blocks are allocated for files:  Contiguous allocation  Linked allocation  Indexed allocation
  • 13. 11.13 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8th Edition Contiguous Allocation  Each file occupies a set of contiguous blocks on the disk  Best-fit ,first-fit or worst-fit algorithm  Directory entry contains starting block number and file size(in blocks)  Good for sequential and random access  Simple – only starting location (block #) and length (number of blocks) are required.  Disadvantage  Disk will become fragment  Difficult to grow file  Advantages  Easy to implement  Excellent read performance
  • 14. 11.14 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8th Edition Contiguous Allocation  Mapping from logical to physical LA/512 Q R Block to be accessed = ! + starting address Displacement into block = R
  • 15. 11.15 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8th Edition Contiguous Allocation of Disk Space
  • 16. 11.16 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8th Edition Extent-Based Systems  Here, a contiguous chunk of space is allocated initially; then, if that amount proves not to be large enough, another chunk of contiguous space, known as an extent is added  The location of a file's blocks is then recorded as a location and a block count, plus a link to the first block of the next extent.  Many newer file systems (I.e. Veritas File System) use a modified contiguous allocation scheme  Extent-based file systems allocate disk blocks in extents  An extent is a contiguous block of disks  Extents are allocated for file allocation  A file consists of one or more extents.
  • 17. 11.17 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8th Edition Linked Allocation  Each file is a linked list of disk blocks: blocks may be scattered anywhere on the disk. pointer block =
  • 18. 11.18 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8th Edition Linked Allocation (Cont.)  Simple – need only starting address  Free-space management system – no waste of space  No random access  Mapping Block to be accessed is the Qth block in the linked chain of blocks representing the file. Displacement into block = R + 1 File-allocation table (FAT) – disk-space allocation used by MS-DOS and OS/2. LA/511 Q R
  • 19. 11.19 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8th Edition Linked Allocation
  • 20. 11.20 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8th Edition File-Allocation Table An illustrative example is the FAT structure shown in Figure 11.7 for a file consisting of disk blocks 217, 618, and 339.
  • 21. 11.21 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8th Edition Linked Allocation  Advantages  No external fragmentation  File size can increase  Disadvantages  Large seek time .  Random access difficult  Overhead of pointers
  • 22. 11.22 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8th Edition Indexed Allocation  Linked allocation solves the external-fragmentation and size-declaration problems of contiguous allocation.  However, in the absence of a FAT, linked allocation cannot support efficient direct access, since the pointers to the blocks are scattered with the blocks themselves all over the disk and must be retrieved in order.  Indexed Allocation solves this problem by bringing all the pointers together into one location the index block.
  • 23. 11.23 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8th Edition Indexed Allocation  Brings all pointers together into the index block.  Logical view. index table
  • 24. 11.24 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8th Edition Example of Indexed Allocation
  • 25. 11.25 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8th Edition Indexed Allocation (Cont.)  Need index table  Random access  Dynamic access without external fragmentation, but have overhead of index block.  Mapping from logical to physical in a file of maximum size of 256K words and block size of 512 words. We need only 1 block for index table. LA/512 Q R Q = displacement into index table R = displacement into block
  • 26. 11.26 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8th Edition Indexed Allocation  Every file must have an index block so it should be as small as possible. But if it is too small, it will not be able to hold enough pointers for a large file and a mechanism will have to be available to deal with this issue. Mechanisms for this purpose include –  Linked Scheme: An index block is normally one disk block. Thus, it can be read and written directly by itself. To allow for large files, we may link together several index blocks.  Multilevel index: A variant of the linked representation is to use a first level index block to point to a set of second – level index blocks.  Combined scheme: Another alternative, used in the UFS, is to keep the first, say, 15 pointers of the index block in the file’s inode.
  • 27. 11.27 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8th Edition Indexed Allocation – Mapping (Cont.)  outer-index index table file
  • 28. 11.28 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8th Edition Combined Scheme: UNIX (4K bytes per block) Unix inode
  • 29. 11.29 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8th Edition Free-Space Management  Since disk space is limited, we should reuse the space from deleted files for new files. To keep track of free disk space, the system maintains a free space list.  The free space list records all free disk blocks – those not allocated to some file or directory. This free space list can be implemented as one of the following:  Bit vector – free space list is implemented as a bit map or a bit vector. Each block is represented by one bit. If the block is free, bit is 1, if the block is allocated, bit is 0.
  • 30. 11.30 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8th Edition Free-Space Management  Bit vector (n blocks) … 0 1 2 n-1 bit[i] =  0  block[i] free 1  block[i] occupied Block number calculation (number of bits per word) * (number of 0-value words) + offset of first 1 bit The calculation of the block number is (Number of bits per word) * (number of 0-value words) + offset of first 1 bit
  • 31. 11.31 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8th Edition Linked Free Space List on Disk  Linked list – Another approach to free space management is to link together all the free disk blocks keeping a pointer to the first free block in a special location on the disk and caching it in memory. The first block contains a pointer to the next free disk block.  Grouping – A modification of the free list approach is to store the addresses of n free blocks in the first free block.  Counting – Another approach is to take advantage of the fact that several contiguous blocks may be allocated or freed simultaneously when space is allocated with the contiguous allocation algorithm or clustering.
  • 32. 11.32 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8th Edition Linked Free Space List on Disk
  • 33. 11.33 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8th Edition Efficiency and Performance  Efficiency dependent on:  disk allocation and directory algorithms  types of data kept in file’s directory entry  Performance  disk cache – separate section of main memory for frequently used blocks  free-behind and read-ahead – techniques to optimize sequential access  improve PC performance by dedicating section of memory as virtual disk, or RAM disk
  • 34. 11.34 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8th Edition Page Cache and Buffer cache  Most disk controllers include local memory to form an on board cache that is large enough to store entire tracks at a time. Once a seek is performed, the track is read into the disk cache starting at the sector under the disk head. The disk controller then transfers any sector requests to OS. Some systems maintain a separate section of main memory for a buffer cache where blocks are kept under the assumption that they will be used again.  Other systems cache file data using a page cache. The page cache uses virtual memory techniques to cache file data as pages rather than as a file system oriented blocks.
  • 35. 11.35 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8th Edition Page Cache  A page cache caches pages rather than disk blocks using virtual memory techniques  Memory-mapped I/O uses a page cache  Routine I/O through the file system uses the buffer (disk) cache  This leads to the following figure
  • 36. 11.36 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8th Edition I/O Without a Unified Buffer Cache
  • 37. 11.37 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8th Edition Unified Buffer Cache  A unified buffer cache uses the same page cache to cache both memory- mapped pages and ordinary file system I/O  . Several systems use page caching to cache both process pages and file data. This is known as unified buffer cache.
  • 38. 11.38 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8th Edition I/O Using a Unified Buffer Cache
  • 39. 11.39 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8th Edition Recovery  Files and directories are kept both in main memory and on disk, and care must be taken to ensure that system failure does not result in loss of data or in data inconsistency.  Consistency checking – compares data in directory structure with data blocks on disk, and tries to fix inconsistencies  Use system programs to back up data from disk to another storage device (floppy disk, magnetic tape, other magnetic disk, optical)  Recover lost file or disk by restoring data from backup
  • 40. 11.40 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8th Edition Log Structured File Systems  While all reads are impossible to be carried out sequentially (since any file may be accessed at any point of time), we can exploit the efficiency of sequential writes. LFS keeps a small buffer of all writes in a memory segment  A log is simply a data structure which is written only at the head (one could think of the entire disk as a log). Once the log is full, it is written into an unused part of the disk in a sequential manner. New data and metadata (inodes, directories) are accumulated into the buffer cache and written all at once in large blocks (such as segments of 0.5M or 1M).
  • 41. 11.41 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8th Edition Log Structured File Systems  Log structured (or journaling) file systems record each update to the file system as a transaction  All transactions are written to a log  A transaction is considered committed once it is written to the log  However, the file system may not yet be updated  The transactions in the log are asynchronously written to the file system  When the file system is modified, the transaction is removed from the log  If the file system crashes, all remaining transactions in the log must still be performed
  • 42. 11.42 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8th Edition The Sun Network File System (NFS)  Network file systems are commonplace. They are typically integrated with the overall directory structure and interface of the client system. NFS is a good example of a widely used, well-implemented client-server network file system.  Here, we use it as an example to explore the implementation details of network file systems.  An implementation and a specification of a software system for accessing remote files across LANs (or WANs)  The implementation is part of the Solaris and SunOS operating systems running on Sun workstations using an unreliable datagram protocol (UDP/IP protocol and Ethernet
  • 43. 11.43 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8th Edition NFS (Cont.)  Interconnected workstations viewed as a set of independent machines with independent file systems, which allows sharing among these file systems in a transparent manner  A remote directory is mounted over a local file system directory  The mounted directory looks like an integral subtree of the local file system, replacing the subtree descending from the local directory  Specification of the remote directory for the mount operation is nontransparent; the host name of the remote directory has to be provided  Files in the remote directory can then be accessed in a transparent manner  Subject to access-rights accreditation, potentially any file system (or directory within a file system), can be mounted remotely on top of any local directory
  • 44. 11.44 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8th Edition NFS (Cont.)  NFS is designed to operate in a heterogeneous environment of different machines, operating systems, and network architectures; the NFS specifications independent of these media  This independence is achieved through the use of RPC primitives built on top of an External Data Representation (XDR) protocol used between two implementation-independent interfaces  The NFS specification distinguishes between the services provided by a mount mechanism and the actual remote-file-access services
  • 45. 11.45 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8th Edition However, from then on, users on machine Ml can access files in the remote directory in a totally transparent manner. To illustrate file mounting, consider the file system depicted in Figure 11.13, where the triangles represent sub trees of directories that are of interest. The figure shows three independent file systems of machines named U, S1, and S2. At this point, on each machine, only the local files can be accessed. Figure 11.14(a) shows the effects of mounting S1: /usr/shared over U: /usr/local. This figure depicts the view users on U have of their file system. Notice that after the mount is complete, they can access any file within the dir1 directory using the prefix /usr /local/ dir1. The original directory /usr /local on that machine is no longer visible. In Figure 11.14(b), we illustrate cascading mounts. The figure shows the result of mounting S2: /usr /dir2 over U: /usr/local/dir1, which is already remotely mounted from 51. Users can access files within dir2 on U using the prefix /usr/local/dir1. If a shared file system is mounted over a user's home directories on all machines in a network, the user can log into any workstation and get his honce environment.
  • 46. 11.46 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8th Edition Three Independent File Systems
  • 47. 11.47 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8th Edition Mounting in NFS Mounts Cascading mounts
  • 48. 11.48 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8th Edition NFS Mount Protocol  Establishes initial logical connection between server and client  Mount operation includes name of remote directory to be mounted and name of server machine storing it  Mount request is mapped to corresponding RPC and forwarded to mount server running on server machine  Export list – specifies local file systems that server exports for mounting, along with names of machines that are permitted to mount them  Following a mount request that conforms to its export list, the server returns a file handle—a key for further accesses  File handle – a file-system identifier, and an inode number to identify the mounted directory within the exported file system  The mount operation changes only the user’s view and does not affect the server side
  • 49. 11.49 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8th Edition NFS Protocol  Provides a set of remote procedure calls for remote file operations. The procedures support the following operations:  searching for a file within a directory  reading a set of directory entries  manipulating links and directories  accessing file attributes  reading and writing files  NFS servers are stateless; each request has to provide a full set of arguments (NFS V4 is just coming available – very different, stateful)  Modified data must be committed to the server’s disk before results are returned to the client (lose advantages of caching)  The NFS protocol does not provide concurrency-control mechanisms
  • 50. 11.50 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8th Edition Three Major Layers of NFS Architecture  UNIX file-system interface (based on the open, read, write, and close calls, and file descriptors)  Virtual File System (VFS) layer – distinguishes local files from remote ones, and local files are further distinguished according to their file-system types  The VFS activates file-system-specific operations to handle local requests according to their file-system types  Calls the NFS protocol procedures for remote requests  NFS service layer – bottom layer of the architecture  Implements the NFS protocol
  • 51. 11.51 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8th Edition Schematic View of NFS Architecture
  • 52. 11.52 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8th Edition Example: WAFL File System  The WAFL file system from WAFL, the write-anywhere file layout, is a powerful, elegant file system optimized for random writes.  Used on Network Appliance “Filers” – distributed file system appliances  “Write-anywhere file layout”  Serves up NFS, CIFS, http, ftp  Random I/O optimized, write optimized  NVRAM for write caching  Similar to Berkeley Fast File System, with extensive modifications
  • 53. 11.53 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8th Edition The WAFL File Layout
  • 54. 11.54 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8th Edition Snapshots in WAFL
  • 55. 11.55 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8th Edition 11.02
  • 56. Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8th Edition, End of Chapter 11