37
1 File Systems • What is a file system? – A method for storing and accessing files • We’ll concentrate on: – User interface to files • Naming, access – System representation of and access to files • Structure, protection – Translation between user and system views

File Systems

Embed Size (px)

DESCRIPTION

File Systems. What is a file system? A method for storing and accessing files We’ll concentrate on: User interface to files Naming, access System representation of and access to files Structure, protection Translation between user and system views. File System Components. Disk Management - PowerPoint PPT Presentation

Citation preview

Page 1: File Systems

1

File Systems

• What is a file system?– A method for storing and accessing files

• We’ll concentrate on:– User interface to files

• Naming, access

– System representation of and access to files• Structure, protection

– Translation between user and system views

Page 2: File Systems

2

File System Components

• Disk Management– How to arrange collection of disk blocks into files

• Naming– User gives file name, not track 50, platter 5, etc

• Protection– Keep information secure

• Reliability/durability– When system crashes, lost stuff in memory, but want

files to be durable

Page 3: File Systems

3

Long-term Information Storage

1. Must store large amounts of data

2. Information stored must survive the termination of the process using it

3. Multiple processes must be able to access the information concurrently

Page 4: File Systems

4

Characteristics of Secondary Storage

• Large amounts– At least 1 GB

• Slow to access– Milliseconds

• It’s free– Not quite, but close

• It’s there– Hangs around for a long time

Page 5: File Systems

5

User vs. System View of a File

System View of a file User’s View of a File

Block oriented, may be scattered

Byte or record oriented, contiguous

Physical sector #’s Name files

No protection Users protected from each other

Data might be corrupted if machine crashes

Robust to machine failures

Page 6: File Systems

6

File Operations (User Interface)

1. Create

2. Delete

3. Open

4. Close

5. Read

6. Write

7. Append

8. Seek• Change current

offset

9. Get attributes

10.Set Attributes• Modifications times,

protection bits

11.Rename

Page 7: File Systems

7

An Example Program Using File System Calls (1/2)

Page 8: File Systems

8

An Example Program Using File System Calls (2/2)

Page 9: File Systems

9

Alternative Interface: Memory-Mapped Files

• Traditional file interface through system calls1) Open file

2) Read data from file

3) (Possibly) modify files

4) Write data to file

5) Close file

• Would be nicer to:1) Map file into address space, starting at addr. X

2) (possibly) modify elements of X

3) Close file

Page 10: File Systems

10

Memory-Mapped Files, cont

• Use virtual memory:– Provide familiar load/store access to files– Instead of read/write– Use file itself as backing store (no swapfile)– On close, file implicitly written to disk

• Advantages:– Less cumbersome, eliminate a copy

• Disadvantages:– What about large files, synchronizations, sharing?

UNIX provides this: mmap(fileId, virtAddr)

Page 11: File Systems

11

File Types

• Regular files– ASCII or binary

• Executable file (binary) have headers with:

Magic #, text size, data size, etc..

• Directories

• Character/Block special files

Page 12: File Systems

12

Directories (user interface)

• Generally, tree-structured

• Consist of 0 or more files

• Operations:– Create, delete, open, close, read, list– Link

• Same file in multiple directories

– Unlink• Remove a directory entry

Page 13: File Systems

13

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, …)

Page 14: File Systems

14

Types of File Access• Sequential access

– read all bytes/records from the beginning– cannot jump around, could rewind or back up– convenient when medium was ma tape

• Direct access (random access)– bytes/records read in any order– essential for data base systems– read can be …

• move file marker (seek), then read or …• read and then move file marker

• Content-based access– “find a certain type of data, e.g. person under 25

years old; this is really a database search

Page 15: File Systems

15

How are files typically used?

• Most files are small (for example .login, .c files)• Large files use up most of the disk space

– Ex: image processing, multimedia

• Large files account for most of the bytes transferred to/from disk

Bad News: need everything to be efficient– Need small files to be efficient, since lots of them– Need large files to be efficient, since most of the disk

space, most of the I/O due to them

Page 16: File Systems

16

File System Implementation

• Need to decide– How to translate between user and system

view– How to store file on disk– How system accesses file on disk– How to manage disk spaces

Page 17: File Systems

17

Some Attributes of Open Files

• Offset

• Protection bits

• File size

• Modification times

• Pointers to disk blocks

• Open count

• Cache

Page 18: File Systems

18

Translating Between User and System (single-process OS only)

• Example:– fileId = Open (“foo”);– Read(buf, nbytes, filedId);

• Open creates new openfile table entry

• On read, fileId indexes into openfile table

• Openfile table contains:– Everything on last slides

Page 19: File Systems

19

Translating Between User and System (multiprogrammed OS)

• Same interface– Open, followed by Read

• More complicated implementation– Need to worry about files sharing– UNIX

• File descriptor points to system-wide table• System wide-table contains offset, protection,

pointer to “I-node”• I-node contains pointers to blocks, file size, etc.

Page 20: File Systems

20

In-Memory File System Structures

Page 21: File Systems

21

How is file stored?

• Contiguous allocation

• Linked allocation– Couple variation

• Indexed allocation– Many variation

Page 22: File Systems

22

Contiguous Allocation

• User must give file size in advance• Find free space on disk using first fit/best fit• Advantages

– Fast sequential access– Fast random (direct) access

• Disadvantages– External fragmentation– Hard to increase file size (moving it very expensive)

Page 23: File Systems

23

Linked Allocation

• Hard to increase file size with contiguous• So, use linked blocks

– Each block contains pointer to next block– Allows blocks to reside anywhere on disk– This is main advantage – can increase file size

• However– Sequential access: seek between each block– Direct access: horrible– Unreliable (lose block, lose rest of file)

Page 24: File Systems

24

FAT (File Allocation Table)

• Used in MS-DOS

• Basically an offshoot of linked allocation– Keep the linked list in a separate part of the

disk• Read FAT into memory (or cache it)• Find block by traversing FAT• Then go get it on disk

– Reduces number of disk reads

Page 25: File Systems

25

Indexed Allocation

• Still want to put free block anywhere on disk

• Bring together all pointers into one block– “index block”– File creation: set pointers to NULL– On write, find free block on disk, set pointer– Direct access: read index block, find right

block• Similar mechanism to paging

Page 26: File Systems

26

Index Block Problems

• How big should index block be?– Too large =>waste space for small files– Too small => painful when gets too large

• Options for large files– Link index blocks– Multilevel index

• Read bunch of index blocks, then get data• Bad for small files

– Combined scheme

Page 27: File Systems

27

Combined Scheme (UNIX)

• Keep some pointers to disk blocks• Keep a few indirect pointers to index

blocks• Example (UNIX 4.2)

– I-node contains 15 pointers• 12 to disk blocks (data)• 1 each to single, double, triple indirect block

– Relatively simple, extensible, small files good– Large files: takes many read

Page 28: File Systems

28

Combined Scheme: UNIX (4K bytes per block)

Page 29: File Systems

29

Implementing Directories (1)

• List– Simple, slow

• O(n) search if list is linear• O(log n) search if kept sorted

• Hashable– More efficient searching– Hash on file name, use result to index into list– Need to choose good has function– UNIX uses this (need to rehash sometimes)

Page 30: File Systems

30

Implementing Directories (2)

(a) A simple directoryfixed size entriesdisk addresses and attributes in directory entry

(b) Directory in which each entry just refers to an i-node

Page 31: File Systems

31

Shared Files (1)

File system containing a shared file

Page 32: File Systems

32

Shared Files (2)

(a) Situation prior to linking

(b) After the link is created

(c) After the original owner removes the file

Page 33: File Systems

33

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

Page 34: File Systems

34

Free-Space Management (Cont.)

• Bit map requires extra space. Example:

block size = 212 bytes

disk size = 230 bytes (1 gigabyte)

n = 230/212 = 218 bits (or 32K bytes)

• Easy to get contiguous files • Linked list (free list)

– Cannot get contiguous space easily– No waste of space

• Grouping • Counting

Page 35: File Systems

35

Free-Space Management (Cont.)

• Need to protect:– Pointer to free list

– Bit map• Must be kept on disk

• Copy in memory and disk may differ.

• Cannot allow for block[i] to have a situation where bit[i] = 1 in memory and bit[i] = 0 on disk.

– Solution:• Set bit[i] = 1 in disk.

• Allocate block[i]

• Set bit[i] = 1 in memory

Page 36: File Systems

36

Linked Free Space List on Disk

Page 37: File Systems

37

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.