trevorb98/CS3841
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge branch 'p-w-rs:master' into master

Browse Source
This commit is contained in:
Trevor
2023-02-23 22:59:16 -06:00
committed by GitHub
parent 67e3f198dd bc7cdcabe0
commit 4fe674e9a6
2 changed files with 2 additions and 209 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
05-JurrasicPark/main.c
View File

@@ -27,7 +27,7 @@
#include "park.h" #include "park.h"
// Jurassic Park // Jurassic Park
extern int begin; extern volatile int begin;
extern JPARK myPark; extern JPARK myPark;
extern pthread_mutex_t parkMutex; // mutex park variable access extern pthread_mutex_t parkMutex; // mutex park variable access
extern pthread_mutex_t fillSeat[NUM_CARS]; // (signal) seat ready to fill extern pthread_mutex_t fillSeat[NUM_CARS]; // (signal) seat ready to fill
@@ -55,4 +55,4 @@ int main(int argc, char *argv[])
pthread_join(parkTask, NULL); pthread_join(parkTask, NULL);
return 0; return 0;
} }

207
07-FunWithFileSystems/README.md
View File

@@ -128,210 +128,3 @@ Unmount the file system with umount when done. When you have completed the step
2. Look at the image file with hexdump (hexdump –C flash.img | more). NOTE: make sure the image is **unmounted** before you do this. Can you find your files? How about the ones you deleted? How did you find them or why couldn't you? 2. Look at the image file with hexdump (hexdump –C flash.img | more). NOTE: make sure the image is **unmounted** before you do this. Can you find your files? How about the ones you deleted? How did you find them or why couldn't you?
3. Show a capture of the hexdump (of the flash.img) containing the directory entries for the files you added to the image as well as the ones you added and then deleted. What is different? 3. Show a capture of the hexdump (of the flash.img) containing the directory entries for the files you added to the image as well as the ones you added and then deleted. What is different?
4. Remount the image, change directory to the directory where the file system is mounted. Now try to unmount the file system with "umount /media/myimage". Did it work successfully? Why or why not? 4. Remount the image, change directory to the directory where the file system is mounted. Now try to unmount the file system with "umount /media/myimage". Did it work successfully? Why or why not?
## Interpreting a File System - TTFS
Linux supports many file system types. Each has their own intended use along with advantages and disadvantages. New file systems are being developed all the time to fit the needs of newer backing storage and application purposes. In this activity you will be given the format for a new file system (teeny tiny file system – TTFS). Study the file system format and use the information to interpret a binary file containing a TTFS file system image.
TTFS stores files and directories of varying sizes. Each file is allocated one or more blocks of data. An index node (inode) stores information about a file or directory in the file system. A TTFS file system image is a binary file divided into the following regions:
1. File system super block – contains information about the entire file system
2. inode bitmap – a bit map that indicates which inodes are free and which are used to store file information
3. block bitmap – a bit map that indicates which blocks are free and which hare used to store file data
4. inode table – an array of inodes for files and directories in the file system
5. block array – the array of data blocks for files and directories in the file system
An image for TTFS is laid out like this:
![TTFS Image](ttfs.png)
Regions of the file system follow immediately after each other. The super block contains offset values that can be used to find where regions begin. Data blocks are 512 bytes long and are accessed via their block index. The block index is zero based, so the first block is block 0, the second is block 1, etc.
### TTFS Super Block
Each field in the super block is 4 bytes. The offset numbers indicate where the region begins from the ***start of the file system image***. Here is a diagram of each of the fields contained in the super block.
<table style="border-collapse:collapse;" border="1">
<thead>
<tr><th>TTFS Super Block</th></tr>
</thead>
<tbody>
<tr><td>TTFS Magic Value</td></tr>
<tr><td>inode count</td></tr>
<tr><td>block count</td></tr>
<tr><td>offset to inode bitmap</td></tr>
<tr><td>offset to block bitmap</td></tr>
<tr><td>offset to inode table</td></tr>
<tr><td>offset to data blocks</td></tr>
<tr><td>unused pads to 32 bytes</td></tr>
</tbody>
</table>
- TTFS Magic Value – an eye-catcher – must contain the string value "TTFS"
- inode count – The total number of index nodes in the file system (used or unused)
- block count – the total number of blocks in the file system (used or not)
- offset to inode bitmap – the offset (in bytes) from the start of the file system image to the start of the inode bitmap
- offset to block bitmap – the offset (in bytes) from the start of the file system image to the start of the block bitmap
- offset to inode table – the offset (in bytes) from the start of the file system image to the start of the inode table
- offset to data blocks – the offset (in bytes) from the start of the file system image to the start of the data block array
The last field "unused" is just a padding to make the super block 64 bytes (makes it easier to read when printed via a hex dump).
To be a valid TTFS file system the image must begin with the characters "TTFS", this is a common way for operating systems to know which driver to load to interpret file a file system.
The inode count represents the total number of index nodes in the file system. Each file or directory in the file system needs to have an index node. This count tells how many files or directories the file system can support.
The block count represents the total number of data blocks that are in the file system. Each file or directory needs to be allocated at least one block to store data. This count tells how much space is available in the file system.
The inode and block bitmap are arrays of bit representing which inodes and blocks are used for files, and which are not. For example, if a file system had 16 inodes and 2 were used for files, then the remaining inodes would be free. Used inodes are represented with a bit value of 1 and free inodes have a bit value of 0. So, for this example the inode bitmap would contain 2 bytes (8 bits per byte and 16 inodes requires 2 bytes) and would look like this:
```text
Byte 0 Byte 1
Binary: 00000011 00000000
Hexadecimal: 03 00
```
Notice that the numbers are in little endian. In other words, the byte ordering goes from low to high from left to the right, but the bit ordering goes from low to high from right to left.
The super block for a TTFS image consisting of 20 inodes and 100 data blocks would look like this in a hexadecimal dump. NOTE: numbers in an x86 created binary image are little endian.
<pre>
<span style="background:yellow">54 54 46 53</span> <span style="background:lime">14 00 00 00</span> <span style="background:cyan">64 00 00 00</span> <span style="background:magenta">20 00 00 00</span> |TTFS....d... ...|
<span style="background:gray">23 00 00 00</span> <span style="background:darkgrey;color:red">30 00 00 00</span> <span style="background:red">30 05 00 00</span> 00 00 00 00 |#...0...0.......|
</pre>
<code style="background:yellow;color:black">54 54 46 53</code> is the TTFS magic value<br/>
<code style="background:lime;color:black">14 00 00 00</code> is the number of inodes – hex 00 00 00 14 -> 20 in decimal<br/>
<code style="background:cyan;color:black">64 00 00 00</code> is the number of blocks – hex 00 00 00 64 -> 100 in decimal<br/>
<code style="background:magenta;color:black">20 00 00 00</code> is the offset to the inode bitmap – hex 00 00 00 20 -> 32 in decimal<br/>
<code style="background:gray;color:black">23 00 00 00</code> is the offset to the block bitmap – hex 00 00 00 23 -> 35 in decimal<br/>
<code style="background:darkgrey;color:red">30 00 00 00</code> is the offset to the inode table – hex 00 00 00 30 -> 48 in decimal<br/>
<code style="background:red;color:black">30 05 00 00</code> is the offset to the block array – hex 00 00 05 30 -> 1328 in decimal
### TTFS Index Node
An index node contains metadata (data about the data) for a file or directory. The inode table contains an array of inodes, each inode is 64 bytes long and contains several fields.
The structure of an inode is as follows:
![TTFS inode](inode.png)
- U – used bit – a single bit that indicates if this inode is used for a file (or directory) or not
- D – directory bit – a single bit that indicates if this inode is for a regular file or a directory
- block count – (1 byte) the total number of data blocks this file is using
- file name – (22 bytes) a string of characters representing the name of the file (null terminated). The file name in TTFS cannot be longer than 21 characters to make room for the null terminator
- file size – (4 bytes – little endian) represents the total size of the file in bytes. Block are 512 bytes long and a file might not end exactly at the end of a block
- allocated block table – (up to 9 entries 4 bytes each little endian) represents the block numbers that are allocated to this file. The block count indicates which entries in this table are valid. NOTE: Entries in the table indicate the block number for the allocated block number, not an offset in bytes.
The inode for a file consisting of 1 data block, that is using 10 bytes might look like this in a hexadecimal dump:
<pre>
<span style="background:yellow">01</span> <span style="background:lime">01</span> <span style="background:cyan">74 65 73 74 2e 74 78 74</span> 00 00 00 00 00 00 |..test.txt......|
00 00 00 00 00 00 00 00 <span style="background:gray">0a 00 00 00</span> <span style="background:magenta">01 00 00 00</span> |................|
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
..... rest of the inode is zeros .....
</pre>
<code style="background:yellow;color:black">01</code> shows the used bit is on but the directory bit is not<br/>
<code style="background:lime;color:black">01</code> indicates the is 1 used block in the file<br/>
<code style="background:cyan;color:black">74 65 73 74 2e 74 78 74</code> is the name of the file - ASCII text "test.txt"<br/>
<code style="background:gray;color:black">0a 00 00 00</code> is the size of the file in bytes – hex 00 00 00 0a -> 10 in decimal<br/>
<code style="background:magenta;color:black">01 00 00 00</code> is the index of the first (and only) data block – hex 00 00 00 01 -> 1 in decimal
### TTFS Directory
Directories (folders) in TTFS are special files. The inode for a directory has the directory bit flipped to indicate that is a directory and not an ordinary file. The data blocks for a directory entry to not contain file data. Instead, they indicate the inodes for the files (or directories) that are contained in the directory. The structure for a directory entry data block is:
![TTFS Directory Block](dirblock.png)
The first 4 bytes indicates an integer number (little endian) of the number of entries contained in the block. The rest of the data block contains 4-byte integers (little endian) for the inodes for entries (files or directories).
For example, consider a directory 'mydir' that contains two files 'file1.txt' and 'file2.txt'
![Directory](dir.png)
The inode for 'mydir' (inode 3) would contain a single data block. The directory data block would look like:
<pre>
<span style="background:yellow">02 00 00 00</span> <span style="background:lime">05 00 00 00</span> <span style="background:cyan">06 00 00 00 00</span> 00 00 00 |................|
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
..... rest of the block is zeros .....
</pre>
<code style="background:yellow;color:black">02 00 00 00</code> is the number of files in the block<br/>
<code style="background:lime;color:black">05 00 00 00</code> is the inode number for file1.txt – hex 00 00 00 05 -> 5 in decimal<br/>
<code style="background:cyan;color:black">06 00 00 00</code> is the inode number for file2.txt – hex 00 00 00 06 -> 6 in decimal<br/>
TTFS always contains a single special directory with no name (the file name is all zeros). This directory represents the root directory of the file system. All files and directories are contained in the root directory. The root director will always use inode 0.
NOTE: a TTFS directory might use multiple data blocks. Each data block has the same structure. This allows for more than 127 entries in a directory (512 / 4 = 128 but one 4-byte value is used for the entry count).
Download the [ttfs.img](ttfs.img) file. This contains a binary image for a TTFS file system. Using the output from hexdump -C and the specification for TTFS answer the following questions:
NOTE: All integers are stored as little endian on x86. So, make sure you read the values correctly
1. What is the largest file that TTFS can support? How did you compute this number?
2. What is the maximum number of files that can exist in a single TTFS directory? HINT: a TTFS directory might have more than one data block.
For the following questions refer to the [ttfs.img](ttfs.img) provided:
5. How may inodes and data blocks are in the file system?
6. How many inodes are free (not used by files or directories?
7. Draw a diagram of the directory hierarchy, include this diagram with your submission.
8. What are the names and sizes of each file in the file system?
9. How many blocks is each file in the file system?
10. For each file, what is the offset (from the start of the file system) for each data block? How did you compute this?
11. Find one of the text files in the file system. Write the data (as a string) for the file contents. How were you able to find the data?
## Extra Credit - TTFS Dump
Using the specification from "Interpreting a File System - TTFS" and the included header file [ttfs.h](ttfs.h) that defines the file system structures, write a program that will read in a TTFS file system image and print the directory structure and contents for each file. For example:
```text
user@pc:~$ ttfsdump ./ttfstest.img
/file2.txt – 10 bytes
(the contents of file2.txt printed here)
/dir1/file1.txt – 100 bytes
(the contents of file1.txt printed here)
/dir1/dir2/file3.txt – 20 bytes
(the contents of file3.txt printed here)
(continue for all files)
```
Also add the following in your report:
- Design – a description of your design decisions in creating your solution
- Build – instructions on how to build and run your program. Include the exact commands that are necessary
Include your source code along with your report in your Canvas submission.
## Deliverables
You will need to include all your source files (if any) and any resources you used to complete lab. Please don't just google search for a solution, but if you do use Google for any help, include a description and URL of what you used to help you.
Once you've completed all the lab activities and have answers to all the lab questions, create a report (text, doc, or pdf file) including the following:
- Your name, section, date, and lab title
- Introduction – a description the lab in your own words
- Resources – a description of any external resources you used to complete the lab
- Analysis – a description of your experiences working with file systems in Linux as a result of this lab
- Include the answers to the questions asked in the lab.
- Conclusion
- Summary of what you learned in the lab
- What specifically was challenging about this lab?
- What did you like about it?
- What could we do to improve it for others?
Be sure to include documentation of any external resources (man pages, stackoverflow, etc.) that you used to complete the lab.
Upload your report to Canvas per your instructor's instructions.
## Grading Criteria
- (5 Points) Report Introduction - Thorough description of the lab in your own words.
- (5 Points) Conclusion - Thorough conclusion with description of what you learned, what you liked, and suggestions for lab improvements.
- (5 Points) Documentation of Resources - Description of external resources used to complete the lab.
- (25 Points) Create and Mount a RAM disk - Responses to the "create a RAM disk" questions
- (25 Points) Mount a File as a File System - Responses to the "file as a file system" questions
- (35 Points) Interpreting a File System - TTFS - Responses to the TTFS interpretation questions
- (10 Points) Bonus - Implementation of the extra credit