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

UNIT-4 & 5 File System & Secondary Storage Structures

The document discusses file systems and how operating systems manage files and storage. It covers topics like file naming, attributes, basic file operations, file structures, directories, paths, allocation methods, and disk structures. It provides details on how operating systems organize storage and access files efficiently.

Uploaded by

Keerthana
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
79 views

UNIT-4 & 5 File System & Secondary Storage Structures

The document discusses file systems and how operating systems manage files and storage. It covers topics like file naming, attributes, basic file operations, file structures, directories, paths, allocation methods, and disk structures. It provides details on how operating systems organize storage and access files efficiently.

Uploaded by

Keerthana
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 68

Unit 5

Storage Management

1
File Systems
 3 criteria for long-term information storage:
 Should be able to store very large amount of information
 Information must survive the processes using it
 Should provide concurrent access to multiple processes
 Solution:
 Store information on disks in units called files
 Files are persistent, and only owner can explicitly delete it
 Files are managed by the OS
 File Systems: How the OS manages files!

 A File system is the data structure that an operating system uses to keep track
of files on a disk or partition

2
File Naming & Extensions
 Each file is associated with a name
 Name divided into 2 parts, first part the name and second part is
the extension
 On UNIX, extensions are not enforced by OS
 However C compiler might insist on its extensions
 These extensions are very useful for C

 Windows attaches meaning to extensions


 Tries to associate applications to file extensions

3
File Attributes
 File-specific info maintained by the OS
 File size, modification date, creation time, etc.
 Varies a lot across different OSes
 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

4
Basic File Operations
 Create a file
 Write to a file
 Read from a file
 Seek to somewhere in a file
 Delete a file

5
 Info Associated with File Open
 File pointer
 File Count / Link Count
 Disk location of the file
 Access rights & locks
 File Types
 Executable
 Object
 Source Code
 Batch
 Text
 Library
 Print or view
 Archive
 Multimedia

6
Internal File Structure
(a) Byte Sequence: unstructured
(b) Record sequence: r/w in records, relates to sector sizes
(c) Complex structures, e.g. tree
- Data stored in variable length records; OS specific meaning of each file

7
File Access
 Sequential access
 read all bytes/records from the beginning
 cannot jump around, could rewind or forward
 convenient when medium was magnetic tape
 editors and compilers usually access files in this fashion
 read next, Writenext, Reset
 Random access
 bytes/records read in any order
 essential for database systems

 Read(n) , Write(n), position to n


[then uses readnext, writenext]
 n represents the block number

8
FS on disk
 Could use entire disk space for a FS, but
 A system could have multiple FSes
 Want to use some disk space for swap space
 Disk divided into partitions, slices or minidisks
 Chunk of storage that holds a FS is a volume
 Directory structure maintains info of all files in the volume
 Name, location, size, type, …

9
Directories
 Directories/folders keep track of files
 Is a symbol table that translates file names to directory entries
 Usually are themselves files
 How to structure the directory to optimize all of the following:
 Search a file
 Create a file Directory
 Delete a file
 List directory
 Rename a file
 Traversing the FS

Files
F1 F2 F4
F3
Fn
10
Single-level Directory
 One directory for all files in the volume
 Called root directory

 Used in early PCs, even the first supercomputer CDC 6600


 Pros: simplicity, ability to quickly locate files
 Cons: inconvenient naming (uniqueness, remembering all)

11
Two-level directory
 Each user has a separate directory

 Solves name collision, but what if user has lots of files


 May not allow a user to access other users’ files

12
Tree-structured Directory
 Directory is now a tree of arbitrary height
 Directory contains files and subdirectories
 A bit in directory entry differentiates files from subdirectories

13
Path Names
 To access a file, the user should either:
 Go to the directory where file resides, or
 Specify the path where the file is
 Path names are either absolute or relative
 Absolute: path of file from the root directory
 Relative: path from the current working directory
 Most OSes have two special entries in each directory:
 “.” for current directory and “..” for parent

14
Acyclic Graph Directories
 Share subdirectories or files

15
Acyclic Graph Directories
 How to implement shared files and subdirectories:
 Why not copy the file?
 New directory entry, called Link (used in UNIX)
 Link is a pointer to another file or subdirectory
 Links are ignored when traversing FS
 ln in UNIX, fsutil in Windows for hard links
 ln –s in UNIX, shortcuts in Windows for soft links
 Issues?
 Two different names (aliasing)
 If dict deletes count  dangling pointer
 Keep backpointers of links for each file
 Leave the link, and delete only when accessed later
 Keep reference count of each file

16
File System Mounting
 Mount allows two FSes to be merged into one
 For example you insert your floppy into the root FS

mount(“/dev/fd0”, “/mnt”, 0)

17
Remote file system mounting
 Same idea, but file system is actually on some other
machine
 Implementation uses remote procedure call
 Package up the user’s file system operation
 Send it to the remote machine where it gets executed like a
local request
 Send back the answer
 Very common in modern systems

18
File-System Structure
 File Structure
 Logical Storage unit
 Collection of related information
 File system is organized into layers

19
File System Layers
 Logical File System
 Provides users the view of a contiguous sequence of words, bytes
 Uses a directory structure, symbolic name
 Provides protection and security

 The file organization module


 Knows about the files and the logical blocks
 Files are organized in blocks of 32 bytes to 4k bytes
 Translates logical blocks into physical

 Basic File System


 Issues commands to the device driver
 Each physical block is identified by a disk address

 I/O Control
 The lowest level in the file system
 Consists of device drivers and interrupt handlers to transfer information between the memory
and the disk

20
Layered File System

21
File-System Implementation
 Boot control block contains info needed by system
to boot OS from that volume
 Volume control block contains volume details
 Directory structure organizes the files
 File Control Block (FCB) contains details about the
file

22
A Typical File Control Block

23
Allocation Methods
An allocation method refers to how disk blocks are
allocated for files:

1. Contiguous allocation
2. Linked allocation
3. Indexed allocation

24
Contiguous Allocation

25
Linked Allocation

26
Indexed Allocation

27
Free Space Management
1. Bit Vector => 1 for block[i] free, 0  block[i] occupied
2. Linked List – free space managed through linked list
3. Grouping – first n-1 block is made free
4. Counting – first block will have the count of the free
blocks

28
Overview of Mass Storage

29
Disk Structure
 Magnetic disks provide bulk of secondary storage of modern
computers:
 Drives rotate at 60 to 200 times per second
 Transfer rate is the rate at which data flow between drive and
computer
 Positioning time is time to move disk arm to desired cylinder
(seek time) and time for desired sector to rotate under the disk
head (rotational latency)
 Head crash results from disk head making contact with the disk
surface
 Disks can be removable

30
Disk Structure

 Disk drives are addressed as large 1-dimensional


arrays of logical blocks, where the logical block is
the smallest unit of transfer
 The 1-dimensional array of logical blocks is mapped
into the sectors of the disk sequentially.
 Sector 0 is the first sector of the first track
 Mapping proceeds in order through that track, then the
rest of the tracks in that cylinder and then through the
rest of the cylinders from outermost to innermost.

31
Disk Scheduling Algorithms
 The operating system is responsible for using hardware efficiently.
 For the disk drives, this means having a fast access time & disk
bandwidth.
 Access time has two major components:
Seek time is the time for the disk to move the heads to the cylinder
containing the desired sector
 Rotational latency time waiting for the disk to rotate the desired sector to the disk
head
 We like to minimize seek time.

32
Disk Scheduling Algorithms
 Disk bandwidth is the total number of bytes
transferred divided by
 the total time between the first request for service and the
completion of the last transfer.
 Several algorithms exist to schedule the servicing of disk
I/O requests.

33
FCFS
 We illustrate them with a Request Queue (cylinder range
0-199):

98, 183, 37, 122, 14, 124, 65, 67

 Head pointer: cylinder 53


 Illustration shows total head movement of 640 cylinders

34
FCFS

35
SSTF
Selects the request with the minimum seek time from
the current head position
SSTF scheduling may cause starvation of some
requests

Illustration shows total head movement of 236 cylinders

36
SSTF

37
SCAN
 The disk arm starts at one end of the disk, and moves toward
the other end, servicing requests until it gets to the other end of
the disk, where the head movement is reversed and servicing
continues.
SCAN algorithm sometimes called the elevator algorithm.
 Illustration shows total head movement of 208 cylinders

38
SCAN

39
C-SCAN
 Provides a more uniform wait time than SCAN
 The head moves from one end of the disk to the other, servicing
requests as it goes
 When it reaches the other end, however, it immediately returns
to the beginning of the disk, without servicing any requests
on the return trip.

 Treats the cylinders as a Circular list that wraps around from the
last cylinder to the first one

40
C-SCAN

41
Look
 LOOK scheduling improves upon SCAN by looking ahead at
the queue of pending requests, and not moving the heads any
farther towards the end of the disk than is necessary.

42
C-LOOK
 Version of C-SCAN
 Arm only goes as far as the last request in each direction, then
reverses direction immediately, without first going all the way to
the end of the disk.

43
C-LOOK

44
Selecting a Disk-Scheduling Algorithm
 SSTF is common and has a natural appeal
 SCAN and C-SCAN perform better for systems that place a
heavy load on the disk

45
Exercise on Disk Scheduling
 Suppose that a disk has 5000 cylinders, numbered 0 to 4999.
The drive is currently serving a request at cylinder 143, and
the previous request was at cylinder 125. The queue of
pending requests is:
86,1470,913,1774,948,1509,1022,1750,130
 Starting from the current head position, what is the total
distance that the disk arm moves to satisfy all the pending
requests for the following disk-scheduling algorithms?
 FCFS
 SSTF
 SCAN

46
Protection
 Protection refers to a mechanism for
controlling the access of programs,
processes, or users to the resources defined
by a computer system.
 Protection ensures that the resources of the
computer are used in a consistent way.
 It ensure that each object accessed correctly
and only by those processes that are allowed
to do so.
47
Goals of Protection
 We need to provide protection for several reasons.
 The most obvious is the need to prevent the
mischievous, intentional violation of an access
restriction by user.
 An unprotected resource cannot defend against
use (or misuse) by an unauthorized or incompetent
user. A protection-oriented system provides means
to distinguish between authorized and
unauthorized usage.
48
Cont…
 Provide a mechanism for the enforcement of the
policies governing resource use.
 These policies can be established in a variety of ways.
- fixed in the design of the system
- formulated by the management of a system
- individual users
 A protection system must have the flexibility to
enforce a variety of policies.

49
Principles of Protection
 The time-tested guiding principle for protection is the
Principle of least privilege. It dictates that programs,
users, and even systems be given just enough privileges
to perform their tasks.
 An operating system following the principle of least
privilege implements its features, programs, system
calls, and data structures so that failure or compromise
of a component does the minimum damage and allows
the minimum damage to be done.
 The principle of least privilege can help produce a more
secure computing environment.
50
Domain of Protection
 A computer system is a collection of processes and
objects. By objects, we mean both hardware objects
(such as the CPU, printer) and software objects(such as
files, programs).
 Each object has a unique name that differentiates it from
all other objects in the system, and each can be accessed
only through well-defined and meaningful operations.

51
Cont…
 A process should be allowed to access only those
resources for which it has authorization
Furthermore, at any time, a process should be able
to access only those resources that it currently
requires to complete its task.

52
Domain Structures
 A process operates within a Protection Domain
that specifies the resources that the process may
access.
 Each domain defines a set of objects and the types
of operations that may be invoked on each object.
 The ability to execute an operation on an object is
an access right.

53
Cont…
 For example, if domain D has the access right
<file F, {read, write}>, then a process executing
in domain D can both read and write file F; it
cannot, however, perform any other operation
on that object.

54
Cont…
 A domain can be realized in a variety of ways:
 Each user may be a domain. In this case, the set of
objects that can be accessed depends on the
identity of the user.
 Each process may be a domain. In this case, the set
of objects that can be accessed depends on the
identity of the process.
 Each procedure may be a domain. In this case, the
set of objects that can be accessed corresponds to
the local variables defined within the procedure.
55
Access Matrix
 Protection can be viewed abstractly as a matrix,
called an Access Matrix. The rows of the
access matrix represent domains, and the
columns represent objects. Each entry in the
matrix consists of a set of access rights.

56
Access Matrix:

57
Use of Access Matrix
 If a process in Domain Di tries to do “op” on object
Oj, then “op” must be in the access matrix
 User who creates object can define access column
for that object
 Can be expanded to dynamic protection
 Operations to add, delete access rights
 Special access rights:
 owner of Oi
 copy op from Oi to Oj (denoted by “*”)
 control – Di can modify Dj access rights
 transfer – switch from domain Di to Dj
 Copy and Owner applicable to an object
 Control applicable to domain object
58
Access Matrix of Figure A with Domains as Objects

59
Access Matrix with Copy Rights

60
Access Matrix With Owner Rights

61
Modified Access Matrix of Figure B

62
Implementation of Access Matrix

 Generally, a sparse matrix


 Option 1 – Global table
 Store ordered triples <domain, object,
rights-set> in table
 A requested operation M on object Oj within domain Di -
> search table for < Di, Oj, Rk >
 with M ∈ Rk
 But table could be large -> won’t fit in main memory
 Difficult to group objects (consider an object that all
domains can read)

63
Implementation of Access Matrix (Cont.)

 Option 2 – Access lists for objects


 Each column implemented as an access list for one
object
 Resulting per-object list consists of ordered pairs
<domain, rights-set> defining all domains
with non-empty set of access rights for the object
 Easily extended to contain default set -> If M ∈ default
set, also allow access

64
Implementation of Access Matrix (Cont.)

 Each column = Access-control list for one object


Defines who can perform what operation
Domain 1 = Read, Write
Domain 2 = Read
Domain 3 = Read

 Each Row = Capability List (like a key)


For each domain, what operations allowed on what
objects
Object F1 – Read
Object F4 – Read, Write, Execute
Object F5 – Read, Write, Delete, Copy

65
Implementation of Access Matrix (Cont.)

 Option 3 – Capability list for domains


 Instead of object-based, list is domain based
 Capability list for domain is list of objects together with
operations allows on them
 Object represented by its name or address, called a capability
 Execute operation M on object Oj, process requests operation and
specifies capability as parameter
 Capability list associated with domain but never directly accessible
by domain
 Rather, protected object, maintained by OS and accessed
indirectly
 Like a “secure pointer”
 Idea can be extended up to applications

66
Implementation of Access Matrix (Cont.)
 Option 4 – Lock-key
 Compromise between access lists and capability lists
 Each object has list of unique bit patterns, called
locks
 Each domain as list of unique bit patterns called
keys
 Process in a domain can only access object if domain
has key that matches one of the locks

67
Comparison of Implementations

 Global table is simple, but can be large


 Access lists correspond to needs of users
 Every access to an object must be checked
 Many objects and access rights -> slow
 Capability lists useful for localizing information
for a given process
 But revocation capabilities can be inefficient
 Lock-key effective and flexible, keys can be
passed freely from domain to domain, easy
revocation

68

You might also like