Filing System Implementation: Difference between revisions

From COMP15212 Wiki
pc>Yuron
No edit summary
gravatar W81054ch [userbureaucratinterface-adminsysopPHRhYmxlIGNsYXNzPSJ0d3BvcHVwIj48dHI+PHRkIGNsYXNzPSJ0d3BvcHVwLWVudHJ5dGl0bGUiPkdyb3Vwczo8L3RkPjx0ZD51c2VyPGJyIC8+YnVyZWF1Y3JhdDxiciAvPmludGVyZmFjZS1hZG1pbjxiciAvPnN5c29wPGJyIC8+PC90ZD48L3RyPjwvdGFibGU+] (talk | contribs)
m (1 revision imported)
 
(No difference)

Latest revision as of 10:03, 5 August 2019

On path: Filing 1: Filing System • 2: File Systems • 3: Files • 4: File Attributes • 5: File Types • 6: File Permissions • 7: File Access • 9: Filing System Implementation • 10: I-nodes • 11: Links • 12: File Descriptor
Depends on File Systems

There are (many) different ways to implement a filing system, even if these ‘look’ the same to users: a couple of illustrative examples are given below.

Typical common characteristics:

  • Allocation is done in blocks; a file occupies a set of whole blocks (although the last one may not be completely full).
    • Reflects the way data is stored on disks (and other media).
    • Will hold 2N bytes: somewhere around the 1 KiB size.
    • Reduces the number of items to ‘address’.
    • Not a completely efficient use of space.
  • There will be some blocks used for data and some for the system organisation.


A point to note is that files can vary in number and length. A simple scheme, where files are laid out on a disk as contiguous blocks – in the same way that arrays are organised in RAM – suffers particularly if/when an existing file is extended in length. Most systems will therefore allow the file block placement to be fragmented rather than contiguous, with some way of indexing the blocks so that each file specifies its own blocks in the correct order.

Here are a couple of typical schemes:

Despite the ability to lay out blocks at ‘random’, file systems still assume that they will be using magnetic disks (or similar) which are not truly random access devices: it is faster to read successive blocks than scattered ones. Hence the fragmentation of files will cause some slowing down.

Sometimes a disk will be deliberately partitioned to assist with this. Various utility binary files – which are not usually modified – may be kept in a separate partition from the user files which change and are reorganised frequently. It is changing a partition’s contents which leads to fragmentation, so this means often-wanted files can be kept tidy and not suffer a slow-down.

They may also be arranged to be near to the disk’s index, which also reduces the access time.

(There are many little optimisations which go on ‘behind the scenes’. )


Also refer to: Operating System Concepts, 10th Edition: Chapter 14, pages 564-593