1/23
Looks like no tags are added yet.
Name | Mastery | Learn | Test | Matching | Spaced |
---|
No study sessions yet.
What is a file?
A file is an array of persistent bytes that can be read and written. Persistence is necessary because main memory and other volatile storage lose data when power is turned off. A file system is a collection of these files.
What is the advantage of using inode numbers for file naming in a file system API?
The main advantage of using inode numbers for file naming in a file system API is that they provide a unique and direct identifier for each file within a file system. This allows the system to quickly locate the file's metadata (inode) on disk using the inode number as an index.
What is the disadvantage of using inode numbers for file naming in a file system API?
The main disadvantage of using inode numbers directly in a file system API is that they are hard to remember and have no inherent meaning or organization for humans. This makes it difficult for users to interact with files directly using only inode numbers.
What is the advantage of using a path (string) name for file naming in a file system API?
The primary advantage of using a path (string) name for file naming in a file system API is that it provides a human-friendly and organized way to identify and access files within a directory tree structure. Unlike inode numbers, paths use recognizable names and hierarchical organization, making it easy for users to understand and navigate the file system.
What is the disadvantage of using a path (string) name for file naming in a file system API?
The main disadvantage of using a path (string) name for file naming in a file system API is the expensive traversal required to resolve the path to the actual file. For every access using a path, the system must traverse the directory tree, potentially involving multiple disk reads to find the inode associated with the file.
What is the advantage of using file descriptors for file naming in a file system API?
The main advantage of using file descriptors for file naming in a file system API is that they provide efficient access to a file after it has been opened. Once a file is opened, the file descriptor acts as an index to a cached inode in memory, avoiding the need for repeated and expensive path traversals for subsequent read and write operations.
What is the disadvantage of using file descriptors for file naming in a file system API?
A potential disadvantage is that a file descriptor must first be obtained through an initial open operation, which often involves an expensive path traversal. Therefore, the efficiency of using a file descriptor is dependent on an initial, potentially costly step.
Why are inode numbers considered arbitrary and not meaningful to humans in a file system API?
Inode numbers are considered arbitrary and not meaningful to humans in a file system API because they are simply unique identification numbers assigned by the system. They have no inherent structure or relationship to the file's content, location in the directory tree, or any other human-understandable attribute.
Why is traversal expensive when using a path (string) name for file access in a file system API?
Traversal is expensive when using a path name because the system needs to read through each directory in the path to find the inode of the target file. For example, accessing /etc/bashrc
requires reading the root directory, then the etc
directory, and finally the bashrc
file's inode. These multiple disk reads to get the inode of each directory constitute the "traversal" and make the operation expensive.
How does using file descriptors improve access efficiency in a file system API?
Using file descriptors improves access efficiency in a file system API because they act as indexes to cached inode datain memory. After an initial (potentially expensive) open operation that resolves a path to an inode, subsequent read and write operations using the file descriptor can directly access the file's metadata from memory, avoiding the need for repeated and costly directory traversals.
What is the trade-off between file access efficiency and human readability when choosing a file naming method in a file system API?
The trade-off in choosing a file naming method is that inode numbers are efficient for the system but lack human readability, while path names are human-readable but lead to less efficient access due to expensive traversal. File descriptors offer efficient subsequent access after an initial open operation, bridging the gap but still relying on a path or inode number initially.
Inode Numbers: Efficient for the system but not human-readable.
Path Names: Human-readable but lead to less efficient access due to expensive traversal.
File Descriptors: Provide efficient access for ongoing operations after an initial open, which might use a path and be less efficient initially.
What is the size of a block in the file system?
A common block size in typical file systems is 4 KB (2^12 bytes). Blocks on disk are often the same size as a page in memory.
What is the relationship between the size of a block in the file system and the size of a page in memory?
Blocks on disk are the same size as a page in memory. For example, 4 KB (2^12 bytes) blocks are quite common in typical file systems, and memory pages are often the same size.
How does the size of a block in the file system compare to the size of a page in memory?
Based on the sources, blocks on disk are the same size as a page in memory. For instance, 4 KB (2^12 bytes) blocks are quite common in typical file systems, and memory pages often have the same size.
Why are the size of a block in the file system and the size of a page in memory typically the same?
The size of a block in the file system and the size of a page in memory are typically the same because blocks on disk are the same size as a page in memory. For example, 4 KB (2^12 bytes) blocks are quite common in typical file systems, and memory pages often have the same size.
What methods are used to allocate blocks for files in a file system?
CE-LF: File systems use several methods to allocate blocks for files, including contiguous allocation, extent-based allocation, linked allocation, and File-Allocation Tables (FAT). Real file systems commonly use extent-based, linked/FAT, and multi-level indexed allocation.
What is the method of contiguous allocation for file blocks, and what metadata must be stored for it?
In contiguous allocation, each file is allocated a contiguous set of blocks on the disk. The metadata that must be stored for contiguous allocation includes the starting block of the file and its size.
What is the method of allocation using a small number of extents, and what metadata must be stored for it?
The method of allocation using a small number of extents, also known as extent-based allocation, involves allocating multiple contiguous regions (extents) of blocks to a single file. The metadata that must be stored for this method includes a small array (2-6) designating each extent, where each entry in this array specifies the starting block and the size of that particular extent.
How does linked allocation work for file blocks, and what metadata must be stored for it?
In linked allocation, a file is allocated as a linked list of fixed-sized blocks on disk. The metadata that must be stored includes the location of the first block of the file. Additionally, each block contains a pointer to the next block in the file, or in the case of File-Allocation Table (FAT), the FAT table itself which contains the linked-list information for all files.
What is the File-Allocation-Table (FAT) method, and what metadata must be stored for it?
The File-Allocation Table (FAT) method is a variation of linked allocation where the linked-list information for all files is kept in an on-disk FAT table. The metadata that must be stored includes the location of the first block of the fileand the FAT table itself.
What is the key difference between contiguous allocation and linked allocation in a file system?
The key difference between contiguous allocation and linked allocation lies in how file blocks are organized on disk: contiguous allocation assigns a single, unbroken sequence of blocks to a file, whereas linked allocation uses a linked list of fixed-size blocks that can be scattered across the disk. This linked list is maintained either through pointers within each block or in a separate File-Allocation Table (FAT).
What are the advantages and disadvantages of using a small number of extents for file block allocation?
Advantages:
Extent-based allocation provides still good performance and still simple calculation for accessing file blocks.
It helps reduce external fragmentation compared to contiguous allocation.
Files can grow over time until the allocated number of extents is exhausted.
Metadata:
The metadata required is a small array (2-6) that designates each extent.
Each entry in this array specifies the starting block and the size of that particular extent.
Why is the metadata required for each allocation method important in a file system?
The metadata required for each allocation method is important because it allows the file system to locate all the blocks belonging to a specific file on the disk. This metadata, such as the starting block and size in contiguous allocation, or the pointers to subsequent blocks in linked allocation, is essential for the file system to correctly read and write file data.
How does the File-Allocation-Table (FAT) method manage file blocks, and what is its main limitation?
The File-Allocation Table (FAT) method manages file blocks by keeping the linked-list information for all files in an on-disk FAT table. To access a block, the system needs to consult the FAT table to find the next block in the file's chain. The main limitation of FAT is that it requires reading from two disk locations for every data read - one to access the FAT table and another to access the actual data block.