0% found this document useful (0 votes)
2 views

Unit 6-coos dead locks and file system

This document covers the concepts of deadlocks in operating systems, including definitions, causes, and strategies for prevention, avoidance, detection, and recovery. It outlines necessary conditions for deadlocks, illustrates resource allocation graphs, and discusses various methods to handle deadlocks. Additionally, it introduces file system interfaces, including file concepts, access methods, and protection mechanisms.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
2 views

Unit 6-coos dead locks and file system

This document covers the concepts of deadlocks in operating systems, including definitions, causes, and strategies for prevention, avoidance, detection, and recovery. It outlines necessary conditions for deadlocks, illustrates resource allocation graphs, and discusses various methods to handle deadlocks. Additionally, it introduces file system interfaces, including file concepts, access methods, and protection mechanisms.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 83

Unit -6

File system Interface


&
DEADLOCKS
DEADLOCKS
OPERATING SYSTEM
Deadlocks
What Is In This Chapter?
• What is a deadlock?

• Staying Safe: Preventing and Avoiding Deadlocks

• Living Dangerously: Let the deadlock happen, then


detect it and recover from it.
SYSTEM MODEL
OPERATING SYSTEM
Deadlocks
What Is In This Chapter?
• What is a deadlock?

• Staying Safe: Preventing and Avoiding Deadlocks

• Living Dangerously: Let the deadlock happen, then


detect it and recover from it.
DEADLOCKS
EXAMPLES:

• "It takes money to make money".

• You can't get a job without experience; you can't get experience without a job.

BACKGROUND:

The cause of deadlocks: Each process needing what another process has. This results
from sharing resources such as memory, devices, links.

Under normal operation, a resource allocations proceed like this::

1. Request a resource (suspend until available if necessary ).


2. Use the resource.
3. Release the resource.
DEADLOCKS Bridge Crossing
Example

• Traffic only in one direction.


• Each section of a bridge can be viewed as a resource.
• If a deadlock occurs, it can be resolved if one car backs up (preempt
resources and rollback).
• Several cars may have to be backed up if a deadlock occurs.
• Starvation is possible.
DEADLOCKS DEADLOCK
CHARACTERISATION
NECESSARY CONDITIONS
ALL of these four must happen simultaneously for a deadlock to occur:

Mutual exclusion
One or more than one resource must be held by a process in a non-sharable
(exclusive) mode.

Hold and Wait


A process holds a resource while waiting for another resource.

No Preemption
There is only voluntary release of a resource - nobody else can make a process
give up a resource.

Circular Wait
Process A waits for Process B waits for Process C .... waits for Process A.
DEADLOCKS RESOURCE
ALLOCATION GRAPH
A visual ( mathematical ) way to determine if a deadlock has, or may occur.

G = ( V, E ) The graph contains nodes and edges.

V Nodes consist of processes = { P1, P2, P3, ...} and resource types
{ R1, R2, ...}

E Edges are ( Pi, Rj ) or ( Ri, Pj )

An arrow from the process to resource indicates the process is requesting the
resource. An arrow from resource to process shows an instance of the resource
has been allocated to the process.

Process is a circle, resource type is square; dots represent number of instances of


resource in type. Request points to square, assignment comes from dot.
Pi Pi
Pi
Rj Rj
DEADLOCKS RESOURCE
ALLOCATION GRAPH
• If the graph contains no cycles, then no process is deadlocked.
• If there is a cycle, then:
a) If resource types have multiple instances, then deadlock MAY exist.
b) If each resource type has 1 instance, then deadlock has occurred.

R3 Assigned to P3

Resource allocation graph

P2 Requests P3
DEADLOCKS RESOURCE
ALLOCATION GRAPH

Resource allocation graph


Resource allocation graph with a cycle but no deadlock.
with a deadlock.
DEADLOCKS Strategy
HOW TO HANDLE DEADLOCKS – GENERAL STRATEGIES

There are three methods:

Ignore Deadlocks: Most Operating systems do this!!

Ensure deadlock never occurs using either

Prevention Prevent any one of the 4 conditions from happening.

Avoidance Allow all deadlock conditions, but calculate cycles about to


happen and stop dangerous operations..

Allow deadlock to happen. This requires using both:

Detection Know a deadlock has occurred.

Recovery Regain the resources.


DEADLOCKS Deadlock
Prevention

Do not allow one of the four conditions to occur.

Mutual exclusion:
a) Automatically holds for printers and other non-sharables.
b) Shared entities (read only files) don't need mutual exclusion (and aren’t
susceptible to deadlock.)
c) Prevention not possible, since some devices are intrinsically non-sharable.

Hold and wait:


a) Collect all resources before execution.
b) A particular resource can only be requested when no others are being held.
A sequence of resources is always collected beginning with the same one.
c) Utilization is low, starvation possible.
DEADLOCKS Deadlock
Prevention
Do not allow one of the four conditions to occur.

No preemption:

a) Release any resource already being held if the process can't get an
additional resource.
b) Allow preemption - if a needed resource is held by another process, which
is also waiting on some resource, steal it. Otherwise wait.

Circular wait:

a) Number resources and only request in ascending order.

Each of these prevention techniques may cause a decrease in utilization


and/or resources. For this reason, prevention isn't necessarily the best
technique.
Prevention is generally the easiest to implement.
DEADLOCKS Deadlock
Avoidance
If we have prior knowledge of how resources will be requested, it's possible to determine if
we are entering an "unsafe" state.

Possible states are:

Deadlock No forward progress can be made.

Unsafe state A state that may allow deadlock.

Safe state A state is safe if a sequence of processes exist such that there are
enough resources for the first to finish, and as each finishes and
releases its resources there are enough for the next to finish.

The rule is simple: If a request allocation would cause an unsafe state, do not honor that
request.

NOTE: All deadlocks are unsafe, but all unsafes are NOT deadlocks.
DEADLOCKS Deadlock
Avoidance

NOTE: All deadlocks are unsafe, but all unsafes are NOT deadlocks.

UNSAFE
SAFE
DEADLOCK

Only with luck will O.S. can avoid


processes avoid deadlock.
deadlock.
DEADLOCKS Deadlock Avoidance
Let's assume a very simple model: each process declares its maximum needs. In this
case, algorithms exist that will ensure that no unsafe state is reached. Maximum needs
does NOT mean it must use that many resources – simply that it might do so under
some circumstances.

EXAMPLE: There are multiple instances of


Assume there exists a total of 12 same resources. Eachthe resource
resource in these
is used examples.
exclusively by
a process. The current state looks like this (Safe State):

Process Max Needs Current


Needs
There are 3 free resources P0 10 5
available after current needs
P1 4 2
In this example, < p1, p0, p2 >
is a workable sequence.
P2 9 2
Deadlock
DEADLOCKS Avoidance
Safety Algorithm
A method used to determine if a particular state is safe. It's safe if there exists a
sequence of processes such that for all the processes, there’s a way to avoid deadlock:

The algorithm uses these variables:

Need[I] – the remaining resource needs of each process.


Work - Temporary variable – how many of the resource are currently available.
Finish[I] – flag for each process showing we’ve analyzed that process or not.

need <= available + allocated[0] + .. + allocated[I-1]  Sign of success

Let work and finish be vectors of length m and n respectively.


DEADLOCKS Deadlock
Avoidance
Safety Algorithm
1. Initialize work = available
Initialize finish[i] = false, for i = 1,2,3,..n

2. Find an i such that:


finish[i] == false and need[i] <= work

If no such i exists, go to step 4.

3. work = work + allocation[i]


finish[i] = true
goto step 2

4. if finish[i] == true for all i, then the system is in a safe state.


Bankers algorithm
Bankers algorithm
Bankers algorithm
Example -2
DEADLOCKS Deadlock
Safety Algorithm Avoidance
Do these examples:
Consider a system with: five processes, P0  P4, three resource types, A, B, C.
Type A has 10 instances, B has 5 instances, C has 7 instances.
At time T0 the following snapshot of the system is taken.
Max Requested -- allocated = Need

 Alloc   Req   Avail 


Is the system A B C A B C A B C
in a safe state? P0 0 1 0 7 4 3 3 3 2
P1 2 0 0 0 2 0
P2 3 0 2 6 0 0
P3 2 1 1 0 1 1
P4 0 0 2 4 3 1
DEADLOCKS Deadlock
Safety Algorithm
Avoidance
Do these examples:
Now try it again with only a slight change in the request by P1.
P1 requests one additional resource of type A, and two more of type C.
Request1 = (1,0,2).
Is Request1 < available?

 Alloc   Req   Avail 


Produce the state
chart as if the A B C A B C A B C
request is Granted
and see if it’s safe. P0 0 1 0 7 4 3 1# 3 0#
(We’ve drawn the P1 3# 0 2# 0 2 0
chart as if it’s
granted. P2 3 0 2 6 0 0
P3 2 1 1 0 1 1
Can the request P4 0 0 2 4 3 1
be granted?
DEADLOCKS Deadlock Detection
Need an algorithm that determines SINGLE INSTANCE OF A RESOURCE TYPE
if deadlock occurred.
• Wait-for graph == remove the resources
Also need a means of recovering from the usual graph and collapse edges.
from that deadlock. • An edge from p(j) to p(i) implies that p(j) is
waiting for p(i) to release.
DEADLOCKS Deadlock Detection

SEVERAL INSTANCES OF A RESOURCE TYPE

Complexity is of order m * n * n.

We need to keep track of:

available - records how many resources of each type are available.


allocation - number of resources of type m allocated to process n.
request - number of resources of type m requested by process n.

Let work and finish be vectors of length m and n respectively.


DEADLOCKS Deadlock Detection

1. Initialize work[ ] = available[ ]


For i = 1,2,...n, if allocation[i] != 0 then // For all n processes
finish[i] = false; otherwise, finish[i] = true;

2. Find an i process such that:


finish[i] == false and request[i] <= work

If no such i exists, go to step 4.

3. work = work + allocation[i]


finish[i] = true
goto step 2

4. if finish[i] == false for some i, then the system is in deadlock state.


IF finish[i] == false, then process p[i] is deadlocked.
DEADLOCKS Deadlock Detection

EXAMPLE
We have three resources, A, B, and C. A has 7 instances, B has 2 instances, and C has 6
instances. At this time, the allocation, etc. looks like this:

Is there a  Alloc   Req   Avail 


sequence that will A B C A B C A B C
allow deadlock to
be avoided? P0 0 1 0 0 0 0 0 0 0
Is there more than P1 2 0 0 2 0 2
one sequence that P2 3 0 3 0 0 0
will work?
P3 2 1 1 1 0 0
P4 0 0 2 0 0 2
DEADLOCKS Deadlock Detection

EXAMPLE
Suppose the Request matrix is changed like this. In other words, the maximum amounts to be allocated are
initially declared so that this request matrix results.

Is there now a
sequence that will  Alloc   Req   Avail 
allow deadlock to be
avoided? A B C A B C A B C
P0 0 1 0 0 0 0 0 0 0
USAGE OF THIS P1 2 0 0 2 0 2
DETECTION ALGORITHM P2 3 0 3 0 0 1#
Frequency of check P3 2 1 1 1 0 0
depends on how often a
deadlock occurs and how P4 0 0 2 0 0 2
many processes will be
affected.
DEADLOCKS Deadlock Recovery

So, the deadlock has occurred. Now, how do we get the resources back and gain forward
progress?

PROCESS TERMINATION:

 Could delete all the processes in the deadlock -- this is expensive.


 Delete one at a time until deadlock is broken ( time consuming ).
 Select who to terminate based on priority, time executed, time to completion, needs
for completion, or depth of rollback
 In general, it's easier to preempt the resource, than to terminate the process.

RESOURCE PREEMPTION:

 Select a victim - which process and which resource to preempt.


 Rollback to previously defined "safe" state.
 Prevent one process from always being the one preempted ( starvation ).
DEADLOCKS Deadlock Recovery

COMBINED APPROACH TO DEADLOCK HANDLING:

• Type of resource may dictate best deadlock handling. Look at ease of implementation, and
effect on performance.

• In other words, there is no one best technique.

• Cases include:

Preemption for memory,

Preallocation for swap space,

Avoidance for devices ( can extract Needs from process. )


DEADLOCKS
WRAPUP

In this section we have:

Looked at necessary conditions for a deadlock to occur.

Determined how to prevent, avoid, detect and recover from deadlocks.


Chapter 6: File-System
Interface
Chapter 6:File-System
Interface
• File Concept
• Access Methods
• Directory Structure
• File-System Mounting
• File Sharing
• Protection
Objectives
• To explain the function of file systems
• To describe the interfaces to file
systems
• To discuss file-system design tradeoffs,
including access methods, file sharing,
file locking, and directory structures
• To explore file-system protection
File Concept
• Contiguous logical address space

• Types:
• Data
• numeric
• character
• binary
• Program
File Structure
• None - sequence of words, bytes
• Simple record structure
• Lines
• Fixed length
• Variable length
• Complex Structures
• Formatted document
• Relocatable load file
• Can simulate last two with first method by
inserting appropriate control characters
• Who decides:
• Operating system
• Program
File Attributes
• Name – only information kept in human-readable
form
• Identifier – unique tag (number) identifies file within
file system
• Type – needed for systems that support different
types
• Location – pointer to file location on device
• Size – current file size
• Protection – controls who can do reading, writing,
executing
• Time, date, and user identification – data for
protection, security, and usage monitoring
• Information about files are kept in the directory
structure, which is maintained on the disk
File Operations
• File is an abstract data type
• Create
• Write
• Read
• Reposition within file
• Delete
• Truncate
• Open(Fi) – search the directory structure on
disk for entry Fi, and move the content of
entry to memory
• Close (Fi) – move the content of entry Fi in
memory to directory structure on disk
Open Files
• Several pieces of data are needed to manage
open files:
• File pointer: pointer to last read/write location, per
process that has the file open
• File-open count: counter of number of times a file
is open – to allow removal of data from open-file
table when last processes closes it
• Disk location of the file: cache of data access
information
• Access rights: per-process access mode
information
Open File Locking
• Provided by some operating systems
and file systems
• Mediates access to a file
• Mandatory or advisory:
• Mandatory – access is denied depending
on locks held and requested
• Advisory – processes can find status of
locks and decide what to do
File Locking Example – Java
import java.io.*;
import java.nio.channels.*;
API
public class LockingExample {
public static final boolean EXCLUSIVE = false;
public static final boolean SHARED = true;
public static void main(String arsg[]) throws IOException {
FileLock sharedLock = null;
FileLock exclusiveLock = null;
try {
RandomAccessFile raf = new
RandomAccessFile("file.txt", "rw");
// get the channel for the file
FileChannel ch = raf.getChannel();
// this locks the first half of the file - exclusive
exclusiveLock = ch.lock(0, raf.length()/2,
EXCLUSIVE);
/** Now modify the data . . . */
// release the lock
exclusiveLock.release();
File Locking Example – Java
API (cont)
// this locks the second half of the file -
shared
sharedLock = ch.lock(raf.length()/2+1,
raf.length(), SHARED);
/** Now read the data . . . */
// release the lock
sharedLock.release();
} catch (java.io.IOException ioe) {
System.err.println(ioe);
}finally {
if (exclusiveLock != null)
exclusiveLock.release();
if (sharedLock != null)
sharedLock.release();
}
}
}
File Types – Name, Extension
Access Methods
• Sequential Access
read next
write next
reset
no read after last write
(rewrite)
• Direct Access
read n
write n
position to n
read next
write next
rewrite n
n = relative block number
Sequential-access File
Simulation of Sequential Access on
Direct-access File
Example of Index and Relative
Files
Directory Structure
• A collection of nodes containing information about all files

Directory

Files
F1 F2 F4
F3
Fn

Both the directory structure and the files reside on disk


Backups of these two structures are kept on tapes
Disk Structure
• Disk can be subdivided into partitions

• Disks or partitions can be RAID protected against failure

• Disk or partition can be used raw – without a file system, or formatted


with a file system

• Partitions also known as minidisks, slices


• Entity containing file system known as a volume

• Each volume containing file system also tracks that file system’s info in
device directory or volume table of contents

• As well as general-purpose file systems there are many special-purpose


file systems, frequently all within the same operating system or
computer
A Typical File-system
Organization
Operations Performed on
Directory

• Search for a file


• Create a file
• Delete a file
• List a directory
• Rename a file
• Traverse the file system
Organize the Directory (Logically)
to Obtain

• Efficiency – locating a file quickly


• Naming – convenient to users
• Two users can have same name for
different files
• The same file can have several different
names
• Grouping – logical grouping of files by
properties, (e.g., all Java programs, all
games, …)
Single-Level Directory
• A single directory for all users

Naming problem

Grouping problem
Two-Level Directory
• Separate directory for each user

 Path name
 Can have the same file name for different user
 Efficient searching
 No grouping capability
Tree-Structured Directories
Tree-Structured Directories
(Cont)

• Efficient searching

• Grouping Capability

• Current directory (working directory)


• cd /spell/mail/prog
• type list
Tree-Structured Directories
(Cont)
• Absolute or relative path name
• Creating a new file is done in current directory
• Delete a file
rm <file-name>
• Creating a new subdirectory is done in current directory
mkdir <dir-name>
Example: if in current directory /mail
mkdir count

mail

prog copy prt exp count

Deleting “mail”  deleting the entire subtree rooted by “mail”


Acyclic-Graph Directories
• Have shared subdirectories and files
Acyclic-Graph Directories
(Cont.)
• Two different names (aliasing)

• If dict deletes list  dangling pointer


Solutions:
• Backpointers, so we can delete all pointers
Variable size records a problem
• Backpointers using a daisy chain organization
• Entry-hold-count solution
• New directory entry type
• Link – another name (pointer) to an existing file
• Resolve the link – follow pointer to locate the file
General Graph Directory
General Graph Directory
(Cont.)
• How do we guarantee no cycles?
• Allow only links to file not subdirectories
• Garbage collection
• Every time a new link is added use a cycle
detection
algorithm to determine whether it is OK
File System Mounting
• A file system must be mounted before it
can be accessed
• A unmounted file system (i.e. Fig. 11-
11(b)) is mounted at a mount point
(a) Existing. (b) Unmounted
Partition
Mount Point
File Sharing
• Sharing of files on multi-user systems is
desirable

• Sharing may be done through a protection


scheme

• On distributed systems, files may be shared


across a network

• Network File System (NFS) is a common


distributed file-sharing method
File Sharing – Multiple Users
• User IDs identify users, allowing
permissions and protections to be per-
user

• Group IDs allow users to be in


groups, permitting group access rights
File Sharing – Remote File
Systems
• Uses networking to allow file system access between systems
• Manually via programs like FTP
• Automatically, seamlessly using distributed file systems
• Semi automatically via the world wide web
• Client-server model allows clients to mount remote file systems
from servers
• Server can serve multiple clients
• Client and user-on-client identification is insecure or
complicated
• NFS is standard UNIX client-server file sharing protocol
• CIFS is standard Windows protocol
• Standard operating system file calls are translated into remote
calls
• Distributed Information Systems (distributed naming services)
such as LDAP, DNS, NIS, Active Directory implement unified
access to information needed for remote computing
File Sharing – Failure Modes
• Remote file systems add new failure
modes, due to network failure, server
failure
• Recovery from failure can involve state
information about status of each remote
request
• Stateless protocols such as NFS include
all information in each request, allowing
easy recovery but less security
File Sharing – Consistency
Semantics
• Consistency semantics specify how multiple users are to access a
shared file simultaneously

Tend to be less complex due to disk I/O and network latency (for
remote file systems
• Andrew File System (AFS) implemented complex remote file
sharing semantics
• Unix file system (UFS) implements:
• Writes to an open file visible immediately to other users of the
same open file
• Sharing file pointer to allow multiple users to read and write
concurrently
• AFS has session semantics
• Writes only visible to sessions starting after the file is closed
Protection
• File owner/creator should be able to control:
• what can be done
• by whom

• Types of access
• Read
• Write
• Execute
• Append
• Delete
• List
Access Lists and Groups
• Mode of access: read, write, execute
• Three classes of users
RWX
a) owner access 7  111
RWX
b) group access 6  110
RWX
c) public access 1  001
• Ask manager to create a group (unique name), say G, and add some
users to the group.
• For a particular file (say game) or subdirectory, define an appropriate
access.
owner group public

chmod 761 game

Attach a group to a file


chgrp G game
Windows XP Access-control List
Management
A Sample UNIX Directory
Listing
File Allocation methods
• The allocation methods define how the files are
stored in the disk blocks. There are three main disk
space or file allocation methods.
• Contiguous Allocation
• Linked Allocation
• Indexed Allocation
• The main idea behind these methods is to provide:
• Efficient disk space utilization.
• Fast access to the file blocks.
1. Contiguous Allocation
• In this scheme, each file occupies a contiguous set of blocks on the
disk. For example, if a file requires n blocks and is given a block b as
the starting location, then the blocks assigned to the file will be: b, b+1,
b+2,……b+n-1. This means that given the starting block address and
the length of the file (in terms of blocks required),
• we can determine the blocks occupied by the file.
The directory entry for a file with contiguous allocation contains
• Address of starting block
• Length of the allocated portion.
Contiguous Allocation

Advantages:
•Easy to implement
•Excellent read
performance

Disadvantages:
•Disk will become
fragmented
•Difficult to grow
Non- Contiguous Allocation

Linked List
Non- Allocation
Contiguous
Allocation
Indexed Allocation

• Linked List Allocation


• In this scheme, each file is a linked list of disk blocks which need not
be contiguous. The disk blocks can be scattered anywhere on the disk.
The directory entry contains a pointer to the starting and the ending file
block. Each block contains a pointer to the next block occupied by the
file.
Linked List Allocation

Advantages:
•No external fragmentation
•File size can increase

Disadvantages:
•Large seek time
•Random acess/direct
acess
•Overahead of pointers
Indexed Allocation
• In this scheme, a special block known as the Index
block contains the pointers to all the blocks occupied
by a file.
• Each file has its own index block. The ith entry in the
index block contains the disk address of the ith file
block.
Indexed Allocation
Advantages:
•Support direct
access/random access
•No external fragmentation

Disadvantages :
•Pointer over head
•Multilevel index block

You might also like