Filing System Implementation: Difference between revisions
pc>Yuron No edit summary |
 W81054ch [   PHRhYmxlIGNsYXNzPSJ0d3BvcHVwIj48dHI+PHRkIGNsYXNzPSJ0d3BvcHVwLWVudHJ5dGl0bGUiPkdyb3Vwczo8L3RkPjx0ZD51c2VyPGJyIC8+YnVyZWF1Y3JhdDxiciAvPmludGVyZmFjZS1hZG1pbjxiciAvPnN5c29wPGJyIC8+PC90ZD48L3RyPjwvdGFibGU+] (talk | contribs) m (1 revision imported) |
||
| (2 intermediate revisions by 2 users not shown) | |||
| Line 2: | Line 2: | ||
-->{{Path|Filing|9}}<!-- | -->{{Path|Filing|9}}<!-- | ||
-->{{#invoke:Dependencies|add|File Systems,5}} | -->{{#invoke:Dependencies|add|File Systems,5}} | ||
There are (many) different ways to implement a [[Filing_System | filing | There are (many) different ways to implement a [[Filing_System | filing system]], even if these ‘look’ the same to users: a couple of illustrative examples are given below. | ||
system]], even if these ‘look’ the same to | |||
users: a couple of illustrative examples are given below. | |||
Typical common characteristics: | Typical common characteristics: | ||
| Line 16: | Line 14: | ||
A point to note is that [[Files|files]] can vary in number and length. | A point to note is that [[Files|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 <em>arrays</em> 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 [[Fragmentation|fragmented]] rather than contiguous, with some way of indexing the blocks so that each file specifies its own blocks in the correct order. | ||
A simple scheme, where files are laid out on a disk as contiguous | |||
blocks – in the same way that <em>arrays</em> 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 | |||
[[Fragmentation|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: | Here are a couple of typical schemes: | ||
| Line 30: | Line 21: | ||
*[[Inodes|I-nodes]] | *[[Inodes|I-nodes]] | ||
Despite the <em>ability</em> to lay out blocks at ‘random’, file | Despite the <em>ability</em> 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. | ||
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 [[Disk_Partition|partitioned]] to | Sometimes a disk will be deliberately [[Disk_Partition|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. | ||
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. | |||
<blockquote> | <blockquote> | ||
They may also be arranged to be near to the disk’s index, which also | They may also be arranged to be near to the disk’s index, which also reduces the access time. | ||
reduces the access time. | |||
</blockquote> | </blockquote> | ||
(There are many little optimisations which go on ‘behind the | (There are many little optimisations which go on ‘behind the scenes’. ) | ||
scenes’. ) | |||
---- | ---- | ||
{{BookChapter|14|564-593}} | |||
{{PageGraph}} | {{PageGraph}} | ||
{{Category|Filing System}} | {{Category|Filing System}} | ||
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 |
|---|
