Save
Upgrade to remove ads
Busy. Please wait.
Log in with Clever
or
show password
Forgot Password?
Don't have an account?  Sign up 
Sign up using Clever
or
Username is available taken
show password


Make sure to remember your password. If you forget it there is no way for StudyStack to send you a reset link. You would need to create a new account. Your email address is only used to allow you to reset your password. See our Privacy Policy and Terms of Service.

Already a StudyStack user? Log In

Reset Password
Enter the associated with your account, and we'll email you a link to reset your password.
focusNode
Didn't know it?
click below
 
Knew it?
click below
Don't Know
Remaining cards (0)
Know
0:00
edit
Embed Code - If you would like this activity on your web page, copy the script below and paste it into your web page.

  Normal Size     Small Size show me how

CECS 326 Filesystems

QuestionAnswer
File a named collection of data and metadata
Relative path Working directory
Block device fixed-size block access and random access capability
Working directory the current directory a process operates in
Directory a mapping from filenames to inodes
Hard link a direct reference to an inode via a directory entry
Inode stores file metadata and block pointers
Symlink a path string to another file
Directory entry (dentry) maps filename -> inode number
Link count number of directory entries pointing to an inode
Path resolution Converting a file path into an inode
Mount point a directory where a filesystem is attached
Absolute path root /
File descriptor an integer handle for an open file
Block device exposes fixed-size blocks
File system abstracts block devices into files
Operation affecting metadata create
Operation affecting file data read
Metadata operations matter because filesystem structure and correctness
Purpose of open() reduce repeated path resolution cost
File descriptor an integer handle for an open file
Without open() full path resolution
Block device provides access to raw fixed-size blocks
Block devices are random-access block storage
File is a byte stream abstraction with metadata
Files are built on top of block devices
File metadata is stored in inode
NOT a file attribute CPU frequency
Path resolution is expensive without open() because repeats directory traversal every time
File system abstracts raw block storage
Key idea of file systems they organize raw blocks into meaningful files
Directory evolution two-level to hierarchical to DAG
Final stage adds symbolic and hard links (DAG structure)
Path resolution reads directory entries
/a/b/c requires one read per path component
Optimization for path resolution caching
Single-level requires global uniqueness of filenames
Two-level limitation no sharing between users
Hierarchical directories improve organization and scalability
Hierarchical limitation no sharing via multiple names
Evolution driven by need for organization and multi-user systems
Each component lookup accesses directory entry
Caching is important because it avoids repeated directory reads
DAG adds links between files (hard and soft links)
Object stores simulate hierarchy using encoded key names
Multiple parents allowed in DAG with links
DAG solves file sharing via multiple names
Single-level characterized by a flat global namespace
Single-level limitation name collisions across users
Two-level improves by per-user namespace
Two-level limitation no sub-organization within a user
Hierarchical uses a tree structure
Hierarchical limitation no multiple names for the same file
DAG extends by adding link edges (hard and soft links)
DAG advantages allows file sharing via multiple names
What does DAG stand for? Directed Acyclic Graph
Single-level directory one global namepsace
Two-level based on user ownership
Hierarchical uses tree-based structure
Hierarchical limitation vs DAG inability to support multiple directory entries for same file
Multiple locations allowed in DAG
Evolution to DAG driven by better naming and sharing flexibility
Flat namespace fails due to name collisions in multi-user environments
Modern Unix/Linux resembles DAG with links
DAG structure is tree plus links
Link count represents number of directory entries referencing the inode
Symbolic link stores a path string
rm deletes first a directory entry
Inode freed when link count reaches 0
Hard links cannot cross filesystems because filesystem
Symlinks can cross filesystems because they store path string
Directory entry maps filesystem -> inode number
Hard link another name for the same inode
Hard links are TRUE because they point to the same inode
Key distinction hard links are inode-based, symlinks are path-based
Removing on hard link only remove one directory entry
symlink invalid if the target path is removed
Hard links are "the file itself" because they reference the same inode directly
Multiple filenames without duplication hard link
Key idea of inode storage metadata is separated from filenames
Hard link stores on disk directory entry pointing to inode number
Symlink stores on disk a small file containing a path string
Hard link survives deletion because inode stays alive if link count > 0
Symlink becomes invalid when target file is deleted
Hard links cannot cross filesystems because inode numbers are filesystem-scoped
Symlinks can cross filesystems because they store path strings
Directory targets correct statement symbolic links can target directories
Harlink inode is the same as the target
Symlink inode is distinct from the target
Hard linsk lower overhead because avoid storing path strings and extra inodes
Symlink requires extra storage because block pointers for path storage
Key conceptual differences of hard links vs symbolic links hard links are inode-based, symlinks are path-based
Absolute path starts at root inode
Relative path starts at working directory
After ln a b; ln -s a c; rm a, cat b still succeeds because hard link exists
After same commands, cat c becomes a dangling symlink
Goal of path resolution inode
Inode points to file data blocks on disk
Absolute path begins at root inode (inode 2 in ext systems)
Relative path begins at working directory inode
stat returns info stored in inode
Path resolution works by reading directories, looking up names, and fetching inodes
Created by: MinYoongi67
 

 



Voices

Use these flashcards to help memorize information. Look at the large card and try to recall what is on the other side. Then click the card to flip it. If you knew the answer, click the green Know box. Otherwise, click the red Don't know box.

When you've placed seven or more cards in the Don't know box, click "retry" to try those cards again.

If you've accidentally put the card in the wrong box, just click on the card to take it out of the box.

You can also use your keyboard to move the cards as follows:

If you are logged in to your account, this website will remember which cards you know and don't know so that they are in the same box the next time you log in.

When you need a break, try one of the other activities listed below the flashcards like Matching, Snowman, or Hungry Bug. Although it may feel like you're playing a game, your brain is still making more connections with the information to help you out.

To see how well you know the information, try the Quiz or Test activity.

Pass complete!
"Know" box contains:
Time elapsed:
Retries:
restart all cards