Collaborators: Yanting Zeng, Xiaorui Le and Maolei Tang
Hybrid Data Structure:
RAM -------> performance
RAM could provide performance for computer because the computer could access anything stored in RAM nearly instantly.
However, it cannot hold data as soon as the electricity is cut. Meanwhile, its space is limited due to its fast access.
We need something else to sovle these two kind of issues.
Disk -------> persistence
Disk stores data magnetically, which solving the problem caused be dependency on electricity. Futhermore, it provides
large space for us to store the data. As a tradeoff, it has latency due to its mechanical motion.
Inode:
-- in main memory metadata for file on disk
-- fixed size(per file)
-- include numbers, not names
-- no file name; instead, file name is on the directory entry
-- the block number containing the direct blocks, indirect blocks and
double indirect blocks
-- has a pointer to operations table
Example:
32-bit inode number
16-bit directory entry length
8-bit name length --------> N-byte file name 0≤N≤256, no more than 256 bits
8-bit file type --------> cached from inode for performance
Directories vs regular files:
We have two kind of files in the VFS, one is the regular file while the other is the directory file
The regular file contains the data for a file and os does not interpret its content. However, the directory
file contains the information for that file, which can be interpreted as a series of directory entry
structures describing the files and subdirectories within the directory.
PS: The file type cannot be changed after created
etc
Sectors are concept refered to the disk, blocks are concept refered to the VFS. Usually,
a block contains at least one sector. Files are located in blocks.
How about removing a data for the file system and no one could actualy
retrieve the file?
$rm foo
This is the most naive method to remove a file. Some other processes
might have the data opened and running. Actually, rm file will not clear
the data from a file system. It just makes the data not visible by seting
the bitmap and remove the directory entry without cleaning the data in
in block. As we can see in lab3, the block data are cleaned when we allocate
a new block instead of removing the file.
unlink("foo") --------->remove a directory entry
watch out! link count could stilll be non-zero due to several hard links
assume link count is zero
$ ls -l foo
-rw-r--r-- 1 XXXX staff 21753 Feb 25 17:21 foo
$ln foo bar --------->race condition
$rm foo
1. file permissions checked by 'open'
2. storage for a file with link count 0 is not reclaimed if a process
has the file open
Another method to remove a file deeply.
$shred file --------->open file, stat to get size, overwirte (may use
new blocks for efficiency) with random data, close file, unlink file.
Notice that shred command fill in random data rather than zeroes three
times. Why we do that that? Due to the trace we change from the original
data to zeroes, there is some tools can figure out this trace and recover
it to get original copy. If we always use random data, we could solve this
issue.
PS: The random data comes from /dev/random
How "root" can defeat shred
/dev/rdsk/00 where rdsk block special device
$ /dev/rdsk/00
What happens if we have a bad sector?
Typically, OS makes the I/O system calls fail and exception handler
deals with it.
ln /usr/bin/emacs subdir/bin/emacs
ln /dev/tty subdir/dev/tty
ln /dev/disk/00 subdir/dev/disk/00
open /dev/disk/00 //for read write
ln some other file to accessible location
open("a/b/c/d", O_WRONLY|O_CREAT|O_EXCL) -------->last component special ()
$mkdir a b
$touch a/f b/g
$ln a b/l
$ln b a/k
This is a cycle!
Generate something like: a/k/l/k/l/k/l/f
Solution: leave it to "find" to deal with this condition
link count --------> count of # directory entries pointing at an inode
Don't suffice if there are cycles like ("a", "b")
1. could check for a cycle dynamically
2. prohibit if "a" is a directory
