COMP3000 Operating Systems F23: Tutorial 5 - Revision history

Abdou at 01:12, 25 October 2023

2023-10-25T01:12:45Z

← Older revision		Revision as of 01:12, 25 October 2023
Line 1:		Line 1:
	In this tutorial you will be learning about files and filesystems by experimenting with and extending [https://people.scs.carleton.ca/~abdou/comp3000/f23/tut5/3000test.c 3000test.c], and creating and manipulating local filesystems. '''WARNING:''' Several of the commands here can lead to system corruption and data loss if not properly used. You have been warned. Please use a VM and make backups, when necessary.		In this tutorial you will be learning about files and filesystems by experimenting with and extending [https://people.scs.carleton.ca/~abdou/comp3000/f23/tut5/3000test.c 3000test.c], and creating and manipulating local filesystems. '''WARNING:''' Several of the commands here can lead to system corruption and data loss if not properly used. You have been warned. Please use a VM and make backups, when necessary.


	==Files and inodes==		==Files and inodes==

Abdou at 01:12, 25 October 2023

2023-10-25T01:12:35Z

← Older revision		Revision as of 01:12, 25 October 2023
Line 1:		Line 1:
	In this tutorial you will be learning about files and filesystems by experimenting with and extending [https://people.scs.carleton.ca/~abdou/comp3000/f23/tut5/3000test.c 3000test.c], and creating and manipulating local filesystems. '''WARNING:''' Several of the commands here can lead to system corruption and data loss if not properly used. You have been warned. Please use a VM and make backups, when necessary.		In this tutorial you will be learning about files and filesystems by experimenting with and extending [https://people.scs.carleton.ca/~abdou/comp3000/f23/tut5/3000test.c 3000test.c], and creating and manipulating local filesystems. '''WARNING:''' Several of the commands here can lead to system corruption and data loss if not properly used. You have been warned. Please use a VM and make backups, when necessary.

	~~'''Note: there are two parts of Tasks/Questions, Part A and Part B'''~~

	==Files and inodes==		==Files and inodes==

Abdou: /* Tasks/Questions (Part A) */

2023-10-25T01:12:05Z

Tasks/Questions (Part A)

← Older revision		Revision as of 01:12, 25 October 2023
Line 18:		Line 18:
	#* a symbolic link		#* a symbolic link
	#* a device file (character or block)		#* a device file (character or block)
	# Change 3000test to use <tt>lstat()</tt> rather than stat. How does its behavior change?		# Change 3000test to use <code>lstat()</code> rather than stat. How does its behavior change?
	# Modify 3000test so when it is given a symbolic link it reports the name of the target. Use <tt>readlink(2)</tt> (this notation describes how to access the man page, e.g., <tt>man 2 readlink</tt>).		# Modify 3000test so when it is given a symbolic link it reports the name of the target. Use <code>readlink(2)</code> (this notation describes how to access the man page, e.g., <code>man 2 readlink</code>).
	# Are there files or directories that you cannot run 3000test on? Can you configure file/directory permissions so as to make something inaccessible to 3000test? Note that this is twofold: 1) whether it is completely inaccessible to 3000test ('''nothing can be displayed''', except the error msg); 2) whether it can be accessed for the search ('''no access to file content''').		# Are there files or directories that you cannot run 3000test on? Can you configure file/directory permissions so as to make something inaccessible to 3000test? Note that this is twofold: 1) whether it is completely inaccessible to 3000test ('''nothing can be displayed''', except the error msg); 2) whether it can be accessed for the search ('''no access to file content''').

Abdou: /* Tasks/Questions (Part B) */

2023-10-25T01:11:36Z

Tasks/Questions (Part B)

← Older revision		Revision as of 01:11, 25 October 2023
Line 56:		Line 56:

	==Tasks/Questions (Part B)==		==Tasks/Questions (Part B)==
	# Run <tt>dd if=/dev/zero of=foo bs=8192 count=32K</tt> and use the <tt>ls</tt> command to check it. What is the logical size of the file foo? How much space does it consume on disk? (Hint: Look at the size option to ls). In comparison, create another file with <tt>dd if=/dev/zero of=foo2 bs=8192 seek=31K count=1K</tt>. Any observations?		# Run <code>dd if=/dev/zero of=foo bs=8192 count=32K</code> and use the <code>ls</code> command to check it. What is the logical size of the file foo? How much space does it consume on disk? (Hint: Look at the size option to ls). In comparison, create another file with <code>dd if=/dev/zero of=foo2 bs=8192 seek=31K count=1K</code>. Any observations?
	# Run <tt>mkfs.ext4 foo</tt>. Does foo consume any more space or less? Do the same (<tt>mkfs.ext4 foo2</tt>) to the other file and answer the same question.		# Run <code>mkfs.ext4 foo</code>. Does foo consume any more space or less? Do the same (<code>mkfs.ext4 foo2</code>) to the other file and answer the same question.
	# Create any file in <tt>/mnt</tt> (e.g., <tt>sudo touch test.txt</tt>) and run <tt>sudo mount foo /mnt</tt>. Do you still see the file you just created?		# Create any file in <code>/mnt</code> (e.g., <code>sudo touch test.txt</code>) and run <code>sudo mount foo /mnt</code>. Do you still see the file you just created?
	# Run <tt>df</tt>. What device is mounted on <tt>/mnt</tt>? What is this device?		# Run <code>df</code>. What device is mounted on <code>/mnt</code>? What is this device?
	# Run <tt>sudo umount /mnt</tt>. What have gone away and what is back?		# Run <code>sudo umount /mnt</code>. What have gone away and what is back?
	# Run <tt>dd if=/dev/zero of=foo conv=notrunc count=10 bs=512</tt>. How does the "<tt>conv=notrunc</tt>" change dd's behavior (versus the command in question 1)?		# Run <code>dd if=/dev/zero of=foo conv=notrunc count=10 bs=512</code>. How does the "<code>conv=notrunc</code>" change dd's behavior (versus the command in question 1)?
	# Run <tt>sudo mount foo /mnt</tt>. What error do you get?		# Run <code>sudo mount foo /mnt</code>. What error do you get?
	# What command can you run to make foo mountable again? What characteristic of the file system enables this command to work? (Hint: revisit the instructions of this tutorial if you have no idea)		# What command can you run to make foo mountable again? What characteristic of the file system enables this command to work? (Hint: revisit the instructions of this tutorial if you have no idea)

Abdou: /* Creating, Mounting, and Unmounting Filesystem */

2023-10-25T01:10:50Z

Creating, Mounting, and Unmounting Filesystem

Abdou: /* Tasks/Questions (Part A) */

2023-10-25T00:50:25Z

Tasks/Questions (Part A)

← Older revision		Revision as of 00:50, 25 October 2023
Line 13:		Line 13:

	==Tasks/Questions (Part A)==		==Tasks/Questions (Part A)==
	# Compile and run [https://people.scs.carleton.ca/~~~lianyingzhao~~/comp3000/~~w23~~/tut5/3000test.c 3000test.c]. It takes a filename as an argument and reports information on the file. Try giving it the following and see what it reports:		# Compile and run [https://people.scs.carleton.ca/~abdou/comp3000/f23/tut5/3000test.c 3000test.c]. It takes a filename as an argument and reports information on the file. Try giving it the following and see what it reports:
	#* a regular text file that exists		#* a regular text file that exists
	#* a directory		#* a directory

Abdou: /* General Instructions (same for all tutorials) */

2023-10-25T00:48:54Z

General Instructions (same for all tutorials)

← Older revision		Revision as of 00:48, 25 October 2023
Line 2:		Line 2:

	'''Note: there are two parts of Tasks/Questions, Part A and Part B'''		'''Note: there are two parts of Tasks/Questions, Part A and Part B'''

	~~==General Instructions (same for all tutorials)==~~

	~~<div class="mw-collapsible mw-collapsed">~~
	~~Click on Expand to view.~~
	~~<div class="mw-collapsible-content">~~
	Tutorials are graded based on participation and effort ('''so no need to struggle to have the “correct” answers — what matters is the attempts and sufficient thinking reflected in your answers'''), but you should still turn in your work. Submit your answers on Brightspace as a single text file named "<username>-comp3000-t<n>.txt" (where username is your MyCarletonOne username and n is the tutorial number). The first four lines of this file should be "COMP 3000 Tutorial <n>", your name, student number, and the date of submission. Your submitted answers must at least respond to all the items in the '''Tasks/Questions''' section.

	The deadline is usually four days after the tutorial date (see the actual deadline on the submission entry). Note that the submission entry is enforced by the system, so you may fail to get the effort marks even if it is one minute past the deadline.

	You should also check in with your assigned TA (in person or by responding to a poll if online). Your TA will be your first point of contact when you have questions or encounter any issues during the tutorial session.

	~~You get 1.5 marks for submitting answers that shows your effort and 0.5 for checking in, making this tutorial worth 2 points total.~~

	~~Read through the instructions before starting your work to get an overall picture. When source files are needed, you can download them by clicking on the hyperlink.~~
	~~</div>~~
	~~</div>~~

	==Files and inodes==		==Files and inodes==

Abdou at 00:48, 25 October 2023

2023-10-25T00:48:24Z

← Older revision		Revision as of 00:48, 25 October 2023
Line 1:		Line 1:
	In this tutorial you will be learning about files and filesystems by experimenting with and extending [https://people.scs.carleton.ca/~~~lianyingzhao~~/comp3000/~~w23~~/tut5/3000test.c 3000test.c], and creating and manipulating local filesystems. '''WARNING:''' Several of the commands here can lead to system corruption and data loss if not properly used. You have been warned. Please use a VM and make backups, when necessary.		In this tutorial you will be learning about files and filesystems by experimenting with and extending [https://people.scs.carleton.ca/~abdou/comp3000/f23/tut5/3000test.c 3000test.c], and creating and manipulating local filesystems. '''WARNING:''' Several of the commands here can lead to system corruption and data loss if not properly used. You have been warned. Please use a VM and make backups, when necessary.

	'''Note: there are two parts of Tasks/Questions, Part A and Part B'''		'''Note: there are two parts of Tasks/Questions, Part A and Part B'''

Abdou: Created page with "In this tutorial you will be learning about files and filesystems by experimenting with and extending [https://people.scs.carleton.ca/~lianyingzhao/comp3000/w23/tut5/3000test.c 3000test.c], and creating and manipulating local filesystems. '''WARNING:''' Several of the commands here can lead to system corruption and data loss if not properly used. You have been warned. Please use a VM and make backups, when necessary. '''Note: there are two parts of Tasks/Questions, Part..."

2023-10-25T00:47:25Z

Created page with "In this tutorial you will be learning about files and filesystems by experimenting with and extending [https://people.scs.carleton.ca/~lianyingzhao/comp3000/w23/tut5/3000test.c 3000test.c], and creating and manipulating local filesystems. '''WARNING:''' Several of the commands here can lead to system corruption and data loss if not properly used. You have been warned. Please use a VM and make backups, when necessary. '''Note: there are two parts of Tasks/Questions, Part..."

New page

In this tutorial you will be learning about files and filesystems by experimenting with and extending [https://people.scs.carleton.ca/~lianyingzhao/comp3000/w23/tut5/3000test.c 3000test.c], and creating and manipulating local filesystems. '''WARNING:''' Several of the commands here can lead to system corruption and data loss if not properly used. You have been warned. Please use a VM and make backups, when necessary.

'''Note: there are two parts of Tasks/Questions, Part A and Part B'''

==General Instructions (same for all tutorials)==

<div class="mw-collapsible mw-collapsed">
Click on Expand to view.
<div class="mw-collapsible-content">
Tutorials are graded based on participation and effort ('''so no need to struggle to have the “correct” answers — what matters is the attempts and sufficient thinking reflected in your answers'''), but you should still turn in your work. Submit your answers on Brightspace as a single text file named "<username>-comp3000-t<n>.txt" (where username is your MyCarletonOne username and n is the tutorial number). The first four lines of this file should be "COMP 3000 Tutorial <n>", your name, student number, and the date of submission. Your submitted answers must at least respond to all the items in the '''Tasks/Questions''' section.

The deadline is usually four days after the tutorial date (see the actual deadline on the submission entry). Note that the submission entry is enforced by the system, so you may fail to get the effort marks even if it is one minute past the deadline.

You should also check in with your assigned TA (in person or by responding to a poll if online). Your TA will be your first point of contact when you have questions or encounter any issues during the tutorial session.

You get 1.5 marks for submitting answers that shows your effort and 0.5 for checking in, making this tutorial worth 2 points total.

Read through the instructions before starting your work to get an overall picture. When source files are needed, you can download them by clicking on the hyperlink.
</div>
</div>

==Files and inodes==
In UNIX/Linux filesystems, a filename does not directly refer to the contents of a file. Instead, a filename refers to an inode (as specified in a directory entry --- dentry, of its parent directory), and the inode then refers to the data. An inode is where file metadata is stored. File ownership, timestamps, and permissions are all stored in a file's inode. Regular files are just '''hard links''' connecting a file name to an inode.

In addition to regular files, we also have symbolic links, directories, block devices, character devices, and pipes. Each is its own type of inode.

Note that while you can find out a file's inode, you cannot go from an inode to a pathname or otherwise manipulate an inode directly from userspace - you always have to go through the pathname. The kernel, however, can access individual inodes directly (indeed it has to in order to get to the contents of a file when given a filename).

3000test.c uses stat() to give information on a given inode.

==Tasks/Questions (Part A)==
# Compile and run [https://people.scs.carleton.ca/~lianyingzhao/comp3000/w23/tut5/3000test.c 3000test.c]. It takes a filename as an argument and reports information on the file. Try giving it the following and see what it reports:
#* a regular text file that exists
#* a directory
#* a symbolic link
#* a device file (character or block)
# Change 3000test to use <tt>lstat()</tt> rather than stat. How does its behavior change?
# Modify 3000test so when it is given a symbolic link it reports the name of the target. Use <tt>readlink(2)</tt> (this notation describes how to access the man page, e.g., <tt>man 2 readlink</tt>).
# Are there files or directories that you cannot run 3000test on? Can you configure file/directory permissions so as to make something inaccessible to 3000test? Note that this is twofold: 1) whether it is completely inaccessible to 3000test ('''nothing can be displayed''', except the error msg); 2) whether it can be accessed for the search ('''no access to file content''').

==Creating, Mounting, and Unmounting Filesystem==
In UNIX/Linux systems we always have a single hierarchical namespace for files and directories. Pathnames that start with a <tt>/</tt> are absolute, starting at the top of the namespace, while ones that do not start with a / are relative to the current directory.

The files in this single namespace come from many sources, each of which can have very different semantics. These sources are known as '''filesystems'''.

When first started, a system must have at least one filesystem. This first filesystem is known as the root filesystem and has the contents of <tt>/</tt>. We can then add other filesystems to this initial set of files by '''mounting''' each filesystem on an existing directory.

On Ubuntu 22.04, the root filesystem is ext4 by default and many others are mounted on top of it. For example, a proc filesystem is mounted on <tt>/proc</tt>, a sysfs is mounted on <tt>/sys</tt>. If you run "mount" with no arguments, it lists all the currently mounted filesystems. Note that most of these are virtual filesystems, in that they do not correspond to any persistent storage (like a disk).

If you insert a USB stick on a laptop or desktop running Linux, it must be mounted before you can access its contents. The current convention is for it to be mounted in <tt>/media/</tt><mounting user><tt>/</tt><name of USB stick filesystem>. This usually happens automatically nowadays when the USB stick is plugged in.

To create an ext4 filesystem, you just run

mkfs.ext4 <writable block device> <span style="color:#ff0000">#Do not try it with any <tt>/dev/*</tt></span>

If you were to run this on the root filesystem of your current system, it would reformat your entire disk if it was allowed to complete. In all likelihood the system should prevent you from doing this as the root filesystem (and any mounted filesystem) gets special protections.

To mount a filesystem, you specify the filesystem to be mounted (by its type or by the device) and the mountpoint:

mount /dev/sdb1 /mnt <span style="color:#ff0000">#Do not try it unless you have that block device and want to do it</span>

This would mount the first partition of the second disk on <tt>/mnt</tt>.

Filesystems can be stored on block devices - devices whose contents are accessed by specifying a block index/address. The other main type of device file, character devices, are used for devices where the data is accessed a single byte (character) at a time. Terminals, modems, printers – for example, will generally be represented as a character device.

Note that mount here can identify the filesystem on <tt>/dev/sdb1</tt> by looking at its superblock. The superblock is usually either in block 0 or 1 of a device. The superblock holds metadata of a filesystem, allowing it to be identified and specified. Without the superblock you cannot do anything with a filesystem. Because of its importance, there are backup superblocks in addition to the primary one. The blocks of a filesystem can be classified as either being superblocks, inode blocks, or data blocks.

Sometimes we want to play with a new filesystem but we don't have a physical device to format. If we have free space for a file in our current filesystem, however, we can put a filesystem in a file by using a loopback block device. A loopback block device is a block device where its data is stored in a regular file on another filesystem (rather than on a separate device). If you do filesystem commands with a regular file, it will transparently associate the file with an available loopback block device (e.g., <tt>/dev/loop1</tt>).

Note that inode numbers are filesystem-specific. Thus, the contents of a file are uniquely specified by its filesystem and inode. Only the kernel has to worry about this level of detail; in userspace, a file's full path contains all the necessary information.

Filesystems on persistent storage are always at risk of corruption. File system checker programs (<tt>fsck</tt>) can detect and repair filesystem errors.

==Tasks/Questions (Part B)==
# Run <tt>dd if=/dev/zero of=foo bs=8192 count=32K</tt> and use the <tt>ls</tt> command to check it. What is the logical size of the file foo? How much space does it consume on disk? (Hint: Look at the size option to ls). In comparison, create another file with <tt>dd if=/dev/zero of=foo2 bs=8192 seek=31K count=1K</tt>. Any observations?
# Run <tt>mkfs.ext4 foo</tt>. Does foo consume any more space or less? Do the same (<tt>mkfs.ext4 foo2</tt>) to the other file and answer the same question.
# Create any file in <tt>/mnt</tt> (e.g., <tt>sudo touch test.txt</tt>) and run <tt>sudo mount foo /mnt</tt>. Do you still see the file you just created?
# Run <tt>df</tt>. What device is mounted on <tt>/mnt</tt>? What is this device?
# Run <tt>sudo umount /mnt</tt>. What have gone away and what is back?
# Run <tt>dd if=/dev/zero of=foo conv=notrunc count=10 bs=512</tt>. How does the "<tt>conv=notrunc</tt>" change dd's behavior (versus the command in question 1)?
# Run <tt>sudo mount foo /mnt</tt>. What error do you get?
# What command can you run to make foo mountable again? What characteristic of the file system enables this command to work? (Hint: revisit the instructions of this tutorial if you have no idea)

← Older revision		Revision as of 01:10, 25 October 2023
Line 23:		Line 23:

	==Creating, Mounting, and Unmounting Filesystem==		==Creating, Mounting, and Unmounting Filesystem==
	In UNIX/Linux systems we always have a single hierarchical namespace for files and directories. Pathnames that start with a <tt>/</tt> are absolute, starting at the top of the namespace, while ones that do not start with a / are relative to the current directory.		In UNIX/Linux systems we always have a single hierarchical namespace for files and directories. Pathnames that start with a <code>/</code> are absolute, starting at the top of the namespace, while ones that do not start with a / are relative to the current directory.

	The files in this single namespace come from many sources, each of which can have very different semantics. These sources are known as '''filesystems'''.		The files in this single namespace come from many sources, each of which can have very different semantics. These sources are known as '''filesystems'''.

	When first started, a system must have at least one filesystem. This first filesystem is known as the root filesystem and has the contents of <tt>/</tt>. We can then add other filesystems to this initial set of files by '''mounting''' each filesystem on an existing directory.		When first started, a system must have at least one filesystem. This first filesystem is known as the root filesystem and has the contents of <code>/</code>. We can then add other filesystems to this initial set of files by '''mounting''' each filesystem on an existing directory.

	On Ubuntu 22.04, the root filesystem is ext4 by default and many others are mounted on top of it. For example, a proc filesystem is mounted on <tt>/proc</tt>, a sysfs is mounted on <tt>/sys</tt>. If you run "mount" with no arguments, it lists all the currently mounted filesystems. Note that most of these are virtual filesystems, in that they do not correspond to any persistent storage (like a disk).		On Ubuntu 22.04, the root filesystem is ext4 by default and many others are mounted on top of it. For example, a proc filesystem is mounted on <code>/proc</code>, a sysfs is mounted on <code>/sys</code>. If you run "mount" with no arguments, it lists all the currently mounted filesystems. Note that most of these are virtual filesystems, in that they do not correspond to any persistent storage (like a disk).

	If you insert a USB stick on a laptop or desktop running Linux, it must be mounted before you can access its contents. The current convention is for it to be mounted in <tt>/media/</tt><mounting user><tt>/</tt><name of USB stick filesystem>. This usually happens automatically nowadays when the USB stick is plugged in.		If you insert a USB stick on a laptop or desktop running Linux, it must be mounted before you can access its contents. The current convention is for it to be mounted in <code>/media/</code><mounting user><code>/</code><name of USB stick filesystem>. This usually happens automatically nowadays when the USB stick is plugged in.

	To create an ext4 filesystem, you just run		To create an ext4 filesystem, you just run

	mkfs.ext4 <writable block device> <span style="color:#ff0000">#Do not try it with any <tt>/dev/*</tt></span>		mkfs.ext4 <writable block device> <span style="color:#ff0000">#Do not try it with any <code>/dev/*</code></span>

	If you were to run this on the root filesystem of your current system, it would reformat your entire disk if it was allowed to complete. In all likelihood the system should prevent you from doing this as the root filesystem (and any mounted filesystem) gets special protections.		If you were to run this on the root filesystem of your current system, it would reformat your entire disk if it was allowed to complete. In all likelihood the system should prevent you from doing this as the root filesystem (and any mounted filesystem) gets special protections.
Line 43:		Line 43:
	mount /dev/sdb1 /mnt <span style="color:#ff0000">#Do not try it unless you have that block device and want to do it</span>		mount /dev/sdb1 /mnt <span style="color:#ff0000">#Do not try it unless you have that block device and want to do it</span>

	This would mount the first partition of the second disk on <tt>/mnt</tt>.		This would mount the first partition of the second disk on <code>/mnt</code>.

	Filesystems can be stored on block devices - devices whose contents are accessed by specifying a block index/address. The other main type of device file, character devices, are used for devices where the data is accessed a single byte (character) at a time. Terminals, modems, printers – for example, will generally be represented as a character device.		Filesystems can be stored on block devices - devices whose contents are accessed by specifying a block index/address. The other main type of device file, character devices, are used for devices where the data is accessed a single byte (character) at a time. Terminals, modems, printers – for example, will generally be represented as a character device.

	Note that mount here can identify the filesystem on <tt>/dev/sdb1</tt> by looking at its superblock. The superblock is usually either in block 0 or 1 of a device. The superblock holds metadata of a filesystem, allowing it to be identified and specified. Without the superblock you cannot do anything with a filesystem. Because of its importance, there are backup superblocks in addition to the primary one. The blocks of a filesystem can be classified as either being superblocks, inode blocks, or data blocks.		Note that mount here can identify the filesystem on <code>/dev/sdb1</code> by looking at its superblock. The superblock is usually either in block 0 or 1 of a device. The superblock holds metadata of a filesystem, allowing it to be identified and specified. Without the superblock you cannot do anything with a filesystem. Because of its importance, there are backup superblocks in addition to the primary one. The blocks of a filesystem can be classified as either being superblocks, inode blocks, or data blocks.

	Sometimes we want to play with a new filesystem but we don't have a physical device to format. If we have free space for a file in our current filesystem, however, we can put a filesystem in a file by using a loopback block device. A loopback block device is a block device where its data is stored in a regular file on another filesystem (rather than on a separate device). If you do filesystem commands with a regular file, it will transparently associate the file with an available loopback block device (e.g., <tt>/dev/loop1</tt>).		Sometimes we want to play with a new filesystem but we don't have a physical device to format. If we have free space for a file in our current filesystem, however, we can put a filesystem in a file by using a loopback block device. A loopback block device is a block device where its data is stored in a regular file on another filesystem (rather than on a separate device). If you do filesystem commands with a regular file, it will transparently associate the file with an available loopback block device (e.g., <code>/dev/loop1</code>).

	Note that inode numbers are filesystem-specific. Thus, the contents of a file are uniquely specified by its filesystem and inode. Only the kernel has to worry about this level of detail; in userspace, a file's full path contains all the necessary information.		Note that inode numbers are filesystem-specific. Thus, the contents of a file are uniquely specified by its filesystem and inode. Only the kernel has to worry about this level of detail; in userspace, a file's full path contains all the necessary information.

	Filesystems on persistent storage are always at risk of corruption. File system checker programs (<tt>fsck</tt>) can detect and repair filesystem errors.		Filesystems on persistent storage are always at risk of corruption. File system checker programs (<code>fsck</code>) can detect and repair filesystem errors.

	==Tasks/Questions (Part B)==		==Tasks/Questions (Part B)==