Tutorial 3

Objectives and Outcomes | The Exam Questions Basics | Lab 3: Disk Simulation | Lab 3: File System Simulation | Any Other Issues

Introduction to Disks and Files

1. Objectives and Outcomes

1.1 Objectives

1. To prepare for Lab 3
2. To reflect upon the logical and physical organisations of disks, and how these attributes impinge upon operating system design
3. To reinforce fundamental file system concepts

1.2 Outcomes

1. You should understand the basic models of secondary storage (disks)
2. You should appreciate the tradeoffs involved in designing a file system
3. You should have a finer appreciation of some of the subtleties in modelling OS components

2. The Exam Questions Basics

1. Review what is meant by the terms disk, rotating magnetic media, read/write heads, tracks, sectors, seek time or latency, rotational delay or latency. The following diagram (figure 2.5 from the text) may help you. (You should commit this diagram to memory.)

2. Explain why as a first approximation, seek time is proportional to the difference in track numbers between the current track and desired track. Further explain why as a second approximation, seek time is proportional to the square root of this difference. Hint: use the formula s=0.5at², where s is distance travelled under constant acceleration a in time t.
3. Why is data stored on disks in blocks of several hundred to a several thousand bytes?
4. What are the basic ways of representing a file across a set of disk blocks?
5. Give arguments for and against storing file names with the file.
6. Explain why the design of file systems keeps changing as disk devices get larger and larger.

3. Lab 3: Disk Simulation

The Literate Program

Warning:You do not need to understand the following section: it is included for information and interest only.

The literate program source code of lab 3 is available on-line. See Lab 2 for details of how this is constructed.

Now read on:

Design Issues

In groups of two, discuss what features you think should be represented in a disk simulator for operating system modelling. Bear in mind the range of potential models and purposes for disk simulators, such as

• modelling the magnetic material and the properties of the read/write head as it speeds over the magnetic material, to determine whether data can be accurately written and read, and how dense the recording might be;
• modelling the electromechanical properties of the read/write head and arm, as the disk controller attempts to position the head over a particular track, to determine the optimum seek times;
• modelling the seek and rotational delays to determine the performance of various disk scheduling algorithms; and
• modelling the size and number of disk blocks, to determine how best to implement higher level functionality (such as file systems) upon them.

The last one is of course, this laboratory exercise.

When you have completed your list of features to be modelled, share them with your tutorial classmates, and compile a list on the whiteboard. Get someone to write them all down, and give the list to your tutor.

Python Issues

As you saw in the last tutorial, Python uses reference semantics in assigning structured values. Discuss how this might affect your design. For example, if you were to model transferring a disk block from disk to memory, should it be a reference copy or a value copy?

4. Lab 3: File System Simulation

Design Issues

As for the disk design, discuss in groups, then in plenary, what sort of file system you would model. Pay attention to issues like whether to store a file as contiguous or indexed, how you would manage free blocks, how you would handle directory information. Again, get someone to write down all these suggestions and give the list to your tutor.

5. Any Other Issues

Are there any other issues you would like to discuss?

Document History

This page maintained by John Hurst. Copyright Monash University Copyright Policy	529 accesses since 11 Aug 2008
Generated at 20090716:1819 from an XML file modified on 20080811:1742 Maintainer use only; not generally accessible: Local Server Work Server CSSE Server

842 accesses since 11 Aug 2008, HTML cache rendered at 20120523:0332