28
Copyright ©: Nahrstedt, Angrave, Abdelzaher, Caccamo 1 Files and file allocation

Copyright ©: Nahrstedt, Angrave, Abdelzaher, Caccamo1 Files and file allocation

Embed Size (px)

Citation preview

Page 1: Copyright ©: Nahrstedt, Angrave, Abdelzaher, Caccamo1 Files and file allocation

Copyright ©: Nahrstedt, Angrave, Abdelzaher, Caccamo 1

Files and file allocation

Page 2: Copyright ©: Nahrstedt, Angrave, Abdelzaher, Caccamo1 Files and file allocation

Copyright ©: Nahrstedt, Angrave, Abdelzaher

2

What is an inode? An inode (index node) is a control structure that

contains key information needed by the OS to access a particular file. Several file names may be associated with a single inode, but each file is controlled by exactly ONE inode.

On the disk, there is an inode table that contains the inodes of all the files in the filesystem. When a file is opened, its inode is brought into main memory and stored in a memory-resident inode table.

[classbook at pag.700]

Page 3: Copyright ©: Nahrstedt, Angrave, Abdelzaher, Caccamo1 Files and file allocation

Copyright ©: Nahrstedt, Angrave, Abdelzaher

3

Information in the inode

Page 4: Copyright ©: Nahrstedt, Angrave, Abdelzaher, Caccamo1 Files and file allocation

Copyright ©: Nahrstedt, Angrave, Abdelzaher

4

Directories In Unix a directory is simply a file that contains a

list of file names plus pointers to associated inodes

Inode table

i1

i2

i3

i4

Name1

Name2

Name3

Name4

…Directory

Page 5: Copyright ©: Nahrstedt, Angrave, Abdelzaher, Caccamo1 Files and file allocation

Copyright ©: Nahrstedt, Angrave, Abdelzaher

5

Directories

DIR *opendir(const char *name);

The opendir() function opens a directory stream corresponding to the directory name, and returns a pointer to the directory stream. The stream is positioned at the first entry in the directory.

Page 6: Copyright ©: Nahrstedt, Angrave, Abdelzaher, Caccamo1 Files and file allocation

Copyright ©: Nahrstedt, Angrave, Abdelzaher

6

Directories struct dirent *readdir(DIR *dir);

The readdir() function returns a pointer to a dirent structure representing the next directory entry in the directory stream pointed to by dir. It returns NULL on reaching the end-of-file or if an error occurred. The dirent structure is defined as follows:

struct dirent { ino_t d_ino; /* inode number */ char d_name[256]; /* filename */

… };

Page 7: Copyright ©: Nahrstedt, Angrave, Abdelzaher, Caccamo1 Files and file allocation

Copyright ©: Nahrstedt, Angrave, Abdelzaher

7

Directories

// error handling is not included!struct dirent *entry;DIR *dirp;

dirp = opendir(".");while((entry = readdir(dirp)) != NULL)printf("%s\n",entry->d_name);

closedir(dirp);

Page 8: Copyright ©: Nahrstedt, Angrave, Abdelzaher, Caccamo1 Files and file allocation

Copyright ©: Nahrstedt, Angrave, Abdelzaher

8

readdir() is not thread safe readdir() returns a pointer to a statically allocated

structure; hence the returned pointer points to data which may be overwritten by another call to readdir() on the same directory stream.

The data is not overwritten by another call to readdir() on a different directory stream.

The reentrant version of readdir() is:int readdir_r(DIR *dirp, struct dirent *entry, struct dirent

**result);

pointer to storage allocated by the user

Page 9: Copyright ©: Nahrstedt, Angrave, Abdelzaher, Caccamo1 Files and file allocation

Copyright ©: Nahrstedt, Angrave, Abdelzaher

9

UNIX file structure implementation

Each user has a "file descriptor table“. Each entry in the "file descriptor table" is a pointer to an entry in the system-wide "open file table"

Each entry in the open file table contains a file offset (file pointer) and a pointer to an entry in the "memory-resident i-node table"

If a process opens an already-open file, a new open file table entry is created (with a new file offset), pointing to the same entry in the memory-resident i-node table

If a process forks, the child gets a copy of the "file descriptor table" (and thus the same file offset)

Page 10: Copyright ©: Nahrstedt, Angrave, Abdelzaher, Caccamo1 Files and file allocation

Copyright ©: Nahrstedt, Angrave, Abdelzaher

10

UNIX file structure implementation

[figure from http://pages.cs.wisc.edu/~swift/classes/cs537-sp09/lectures/14-unix-fs.pdf]

Page 11: Copyright ©: Nahrstedt, Angrave, Abdelzaher, Caccamo1 Files and file allocation

Copyright ©: Nahrstedt, Angrave, Abdelzaher

11

File opening

A call to open() creates a new entry (open file description) in the system-wide table of open files. This entry records the file offset and the file status flags.

A file descriptor is a reference to one of these entries. The new open file description is initially not shared with any other process, but sharing may arise via fork.

Page 12: Copyright ©: Nahrstedt, Angrave, Abdelzaher, Caccamo1 Files and file allocation

Copyright ©: Nahrstedt, Angrave, Abdelzaher

12

File Allocation on Disk

Low level access methods for a file depend upon the disk allocation scheme used to store file data

Contiguous Linked list Block or indexed

Page 13: Copyright ©: Nahrstedt, Angrave, Abdelzaher, Caccamo1 Files and file allocation

Copyright ©: Nahrstedt, Angrave, Abdelzaher

13

#1. Contiguous Allocation

Page 14: Copyright ©: Nahrstedt, Angrave, Abdelzaher, Caccamo1 Files and file allocation

Copyright ©: Nahrstedt, Angrave, Abdelzaher

14

Contiguous Allocation Issues

Access method suits sequential and direct access

Directory table maps files into starting physical address and length

Easy to recover in event of system crash Fast, often requires no head movement and

when it does, head only moves one track

Page 15: Copyright ©: Nahrstedt, Angrave, Abdelzaher, Caccamo1 Files and file allocation

Copyright ©: Nahrstedt, Angrave, Abdelzaher

15

Contiguous Allocation Issues

File is allocated large contiguous chunks Expanding the file requires copying Dynamic storage allocation - first fit, best fit External fragmentation occurs on disk

Page 16: Copyright ©: Nahrstedt, Angrave, Abdelzaher, Caccamo1 Files and file allocation

Copyright ©: Nahrstedt, Angrave, Abdelzaher

16

External Fragmentation

Solution: Linked allocation

Page 17: Copyright ©: Nahrstedt, Angrave, Abdelzaher, Caccamo1 Files and file allocation

Copyright ©: Nahrstedt, Angrave, Abdelzaher

17

#2. Linked Allocation

Page 18: Copyright ©: Nahrstedt, Angrave, Abdelzaher, Caccamo1 Files and file allocation

Copyright ©: Nahrstedt, Angrave, Abdelzaher

18

Linked List Allocation

Each file is a linked list of nodes Pointers in list are not accessible to user Directory table maps files into head of list for

a file A node in the list can be a fixed size physical

block or a contiguous collection of blocks Easy to use - no estimation of size necessary

Page 19: Copyright ©: Nahrstedt, Angrave, Abdelzaher, Caccamo1 Files and file allocation

Copyright ©: Nahrstedt, Angrave, Abdelzaher

19

Linked List Allocation

Can grow in middle and at ends Space efficient, little fragmentation Slow - defies the principle of locality. Need

to read through linked list of nodes sequentially to find the needed blocks of data

Suited for sequential access but not direct access

Page 20: Copyright ©: Nahrstedt, Angrave, Abdelzaher, Caccamo1 Files and file allocation

Copyright ©: Nahrstedt, Angrave, Abdelzaher

20

Linked List Allocation Issues

Disk space must be used to store pointers (if disk block is 512 bytes, and disk address requires 4 bytes, then the user sees blocks of 508 bytes)

Not very reliable. System crashes can scramble files being updated

Important variation on linked allocation method: `file-allocation table' (FAT) - OS/2 and MS-DOS

Page 21: Copyright ©: Nahrstedt, Angrave, Abdelzaher, Caccamo1 Files and file allocation

Copyright ©: Nahrstedt, Angrave, Abdelzaher

21

Linked List Allocation Issues

Summary: linked allocation solves the external fragmentation and size-declaration problems of contiguous allocation,

However, it can't support efficient direct access

Page 22: Copyright ©: Nahrstedt, Angrave, Abdelzaher, Caccamo1 Files and file allocation

Copyright ©: Nahrstedt, Angrave, Abdelzaher

22

#3. Indexed Allocation

Page 23: Copyright ©: Nahrstedt, Angrave, Abdelzaher, Caccamo1 Files and file allocation

Copyright ©: Nahrstedt, Angrave, Abdelzaher

23

Indexed Allocation

Solves external fragmentation Supports sequential, direct and

indexed access Access requires at most one

access to index block first. This can be cached in main memory

Page 24: Copyright ©: Nahrstedt, Angrave, Abdelzaher, Caccamo1 Files and file allocation

Copyright ©: Nahrstedt, Angrave, Abdelzaher

24

Indexed Allocation

Requires extra space for index block, possible wasted space

How to extend to big files? A file can be extended by using linked

indexed files or multilevel indexed files

Page 25: Copyright ©: Nahrstedt, Angrave, Abdelzaher, Caccamo1 Files and file allocation

Copyright ©: Nahrstedt, Angrave, Abdelzaher

25

Linked Indexed Files

Link full index blocks together using last entry.

Page 26: Copyright ©: Nahrstedt, Angrave, Abdelzaher, Caccamo1 Files and file allocation

Copyright ©: Nahrstedt, Angrave, Abdelzaher

26

Multilevel Indexed File

Multiple levels of index blocks

Page 27: Copyright ©: Nahrstedt, Angrave, Abdelzaher, Caccamo1 Files and file allocation

Copyright ©: Nahrstedt, Angrave, Abdelzaher

27

Layout of a UNIX file on disk

File allocation is done on a block basis and allocation is dynamic (as needed).

UNIX uses a multilevel indexing mechanism for file allocation on disk. Addresses of first 10 data blocks + 3 index blocks (first, second, and third level of indexing)

In UNIX System V the length of a block is 1 Kbyte and each block can hold a total of 256 block addresses

According to above parameters, maximum size for a file is slightly over 16Gbytes

Page 28: Copyright ©: Nahrstedt, Angrave, Abdelzaher, Caccamo1 Files and file allocation

Copyright ©: Nahrstedt, Angrave, Abdelzaher

28

Layout of a UNIX file on disk

First ten addresses point to the first 10 data blocks of the file

The inode includes 39 bytes of address information that is organized as thirteen 3-byte addresses