File System Implementation: beyond the user’s view A possible file system layout on a disk.

16
Implementation: beyond the user’s view A possible file system layout on a disk.
  • date post

    20-Dec-2015
  • Category

    Documents

  • view

    228
  • download

    0

Transcript of File System Implementation: beyond the user’s view A possible file system layout on a disk.

Page 1: File System Implementation: beyond the user’s view A possible file system layout on a disk.

File System Implementation:beyond the user’s view

A possible file system layout on a disk.

Page 2: File System Implementation: beyond the user’s view A possible file system layout on a disk.

How does the file system keep track of which blocks on the disk go with which

file?

Page 3: File System Implementation: beyond the user’s view A possible file system layout on a disk.

Contiguous Allocation of Disk Space

(a) State of contiguous allocation for 7 files(b) State of the disk after files D and E have been removed

Page 4: File System Implementation: beyond the user’s view A possible file system layout on a disk.

Storing a file as a linked list of disk blocks

Page 5: File System Implementation: beyond the user’s view A possible file system layout on a disk.

Linked list allocation using a File Allocation Table in RAM

Page 6: File System Implementation: beyond the user’s view A possible file system layout on a disk.

An example i-node

Page 7: File System Implementation: beyond the user’s view A possible file system layout on a disk.

Implementing Directories

(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 8: File System Implementation: beyond the user’s view A possible file system layout on a disk.

Implementing Directories (2)

• Two ways of handling long file names in directory– (a) In-line– (b) In a heap

Page 9: File System Implementation: beyond the user’s view A possible file system layout on a disk.

Shared Files•A connection between a directory and a shared file is called a ‘link’.

•Is the following diagram a tree?

Page 10: File System Implementation: beyond the user’s view A possible file system layout on a disk.

What problem can develop with shared files?

When directories actually hold disk addresses, if one owner appends the file, these additional blocks appear in only that directory.

Solutions:

1. Do not list disk blocks in the directory. Include a pointer to an I-node instead, as done in Unix.

2. Use ‘symbolic linking’, where the operating system controls the situation. A file has one ‘owner’ directory. When another directory wishes to share the file, a new type file called ‘LINK’ is created. This file contains the path name of the file and is put in the other directory.

Page 11: File System Implementation: beyond the user’s view A possible file system layout on a disk.

Note: With symbolic links, files on machines around the world can be used by only providing the network address of the machine where the file resides and the path to where it resides on that machine.

However, there is a great deal of overhead:

1. The file containing the path must be read.

2. The path must be parsed and followed one component at a time until the I-node is reached.

All of which requires many, time consuming, disk reads.

Page 12: File System Implementation: beyond the user’s view A possible file system layout on a disk.

Managing Disk SpaceSimilar concerns to managing main memory:

•Store an n byte file in n consecutive bytes OR

•Split up the file into (some number) of not necessarily contiguous blocks of disk space.

This is the same trade-off as pure segmentation and paging. However, which takes more time?

•When a segment grows, moving it to acquire more memory is much faster than moving a file on a disk.

Page 13: File System Implementation: beyond the user’s view A possible file system layout on a disk.

Nearly all file systems use fixed-size, not necessarily contiguous, blocks.

What are block size concerns?

•Small blocks (power of 2, less than 2KB) are bad for performance. Why?

(each read takes seek time and has rotational delay)

but small blocks are good for resource utilization (disk space)

•Large blocks (>2KB) have better data access time (more data is read with each seek)but space is wasted (most files will not fill the last block).

Page 14: File System Implementation: beyond the user’s view A possible file system layout on a disk.

Keeping track of free disk blocks is similar to keeping track of main memory. Two methods are:

1. A linked list of blocks on the disk, each block holding the numbers of the free blocks.

Example: 1 KB blocks could hold 256 free block numbers, if each is a 32 bit integer. Why?

1024 = 210 32 bits = 4 bytes = 22 210 / 22 = 28

Actually, only 255 free block numbers are held, because one slot holds a pointer to the next block.

Does this work with 32 bits?

Yes, if 32 bit addresses are used on the disk.

Page 15: File System Implementation: beyond the user’s view A possible file system layout on a disk.

2. A bitmap is used. Each block on the disk is represented by 1 bit. (free = 1, allocated - 0, or vice versa)

Bitmaps use less disk space, since only 1 bit per block rather than 32 bits for a block number is used.

Page 16: File System Implementation: beyond the user’s view A possible file system layout on a disk.