DOCSLIB.ORG

UNIX File System

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
UNIX File System The UNIX File System * UNIX: a time-sharing system. * UNIX: AT&T version, BSD version (Berkeley Software Distribution). * File: a uniform logical view of information storage. - A file is a collection of related information defined by its creator. * Why file system ? 1) when size of files is large. 2) for back-up. 3) sharing. * We are cared about how files are structed, named, accessed, used, protected, and implemented ==> a file system. * File System: 1) the directory structure. 2) the collection of actual fields. * File structure: byte sequence, record sequence, tree. FileSystem - 1 Ant Fox Pig 1 Byte 1 Record Cat Cow Dog Coat Lion Owl Pony Rat Worm Hen lbis Lamb FileSystem - 2 * File access: 1) sequential access: tape. 2) random access: disk. * Types of files: 1) test files. (characters) 2) source files. 3) object files. (binary files) 4) database. (record) or 1) regular files (user files): ASCII files/binary files. - ASCII files: they can be displayed and printed as is, and they can be edited with an ordinary test editor. - binary files: consists of a collection of library procedures compiled but not linked. 2) directories (system files). 3) character special files: related to I/O terminal, printer, network. 4) block special files (model disk). FileSystem - 3 The UNIX File System * A File system is the organization framework that specifies how a mass storage device is organized. -File systems usually contain a map, which is called the i-node table on the UNIX system, that is used to locate a file, given its name. *UNIX File Types 1) ordinary files: text and binary files. 2) directory files: collections of files. A directory file stores the names of the files it contains plus information that is used to locate and access the files. 3) device files: special device files. A device file is a means of accessing a hardhare device, usually an I/O device. Ex. a pseudo-tty. 4) symbolic link files. A symbolic link is a way to make a new name for an existing files. It makes it easy to place “copies” of things whenever they are needed, without the overlead ( and duplications ) of truly making copies. 5) the named pipes. * File Access Modes + Protection + Security FileSystem - 4 * The directory system can be viewed as a symbol table that translates file names into their directory entries. ==> the directory itself can be organized in many ways. ==> problem: how to search the entry ? 1) linear search. 2) hash. * UNIX directory - files are organized in tree-structured directories. - absolute/relative path name. - working directory. * Implementing Directories - When a file is opened, OS uses the path name supplied by the user to locate the directory entry. The directory entry provides the information needed to find the disk blocks. - Depending on the system, the information may be the disk address of the entire file (continuous allocation), the number of the first block or the number of the I-node (in UNIX). - The main function of the directory system is to map the ASCII name of the file to the information needed to locate the data. - Issue: where the attributes of a file should be stored ? 1) store them directly in the directory entry. 2) i-node: store the attributes in the i-node, rather than directory entry. FileSystem - 5 FileSystem - 6 FileSystem - 7 Directory Description /bin Frequently used system binaries /dev Special files for I/O devices /etc Miscellaneous system administration /lib Frequently used libraries /tmp Some utilities generate their temporary files here /usr All user files are in this part of the tree /usr/adm System accounting /usr/ast Home directory for the user whose login name is ast /usr/bin Other system binaries are kept here /usr/include System header files /usr/lib Libraries, compiler passes, miscellaneous /usr/man Online manuals /usr/spool Spooling directories for printer and other daemous /usr/src System source code /usr/tmp Other utilities put their temporary files here FileSystem - 8 Figure 1 ■ A Simplified Diagram of a Typical UNIX File System In this diagram, directory files are shown in triangles, special device files are shown in diamonds, and ordinary files are shown without borders. FileSystem - 9 * File system implementation - implement file storage; keep track of which disk blocks go with which files. 1) continuous allocation. - simple, good performance. - but not flexible (must know the size of the file in advance), large fragmentation. 2) Link list allocation: a linked list of disk block. - no space is wasted to disk fragmentation. - it is sufficient for the directory entry to merely store the disk address of the first block. - however, reading a file sequentially is straightforward. - random access is slow. FileSystem - 10 3) Linked list allocation using an index. - the entire block is available for date. - random access is much easier. - however, the entire table must be in memory. FileSystem - 11 4) I-node in UNIX. - associate with each file a little table called i-node (index-node), which lists the attributes and disk addresses of the file's blocks. - for small files: all the necessary information is in i-node. - for large files: one of the addresses in i-node is the address of a disk block called a single direct block. - file descriptor is an index to a small table of open files for this process. - in this table, each entry contains an pointer to a file structure, which in trun, points to the i-node. - ls -l after get i-node number, copy i-node information from disk to memory (called in-core i-node). - each i-node contains 15 direct link pointer (each of them pointing to a page <= 12 blocks), 3 inderect block pointers (single, double, triple: indirect block pointer). FileSystem - 12 FileSystem - 13 Inode Filename number UNIX directory entry Mode File table of File Permission Access Modification Number Owner Group Modification Size contents type vector time time Of links time (for file map) UNIX inode Figure 2 block 0 Boot Super Inode Data block block list UNIX File System Figure 3 FileSystem - 14 Figure 3 ■ File Systems Traditionally Used This Simple Layout Figure 4 ■ Disks are Usually Divided into Partitions or Slices FileSystem - 15 Figure 5 ■ File Descriptors, File Table, and Inode Table Figure 6 ■ File System Layout A file system has the following structure ( Figure 6 ). ⚫ The boot block occupies the beginning of a file system, typically the first sector, and may contain the bootstrap code that is read into the machine to boot, or initialize, the operating system. Although only one boot block is needed to boot the system, every file system has a ( possibly empty ) boot book. ⚫ The super block describes the state of a file system – how large it is, how many files it can store, where to find free space on the file system, and other information. ⚫ The inode list is a list of inodes that follows the super block in the file system. Admi nistrators specify the size of the inode list when configuring a file system. The kernel references inodes by index into the inode list. One inode is the root inode of the file system: it is the inode by which the directory structure of the file system is accessible after execution of the mount system call. ⚫ The data blocks start at the end of the inode list and contain file data and administrative data. An allocated data block can belong to one and only one file in the file system. FileSystem - 16 FileSystem - 17 Figure 7 ■ The Kernel Data Structure for Accessing Files FileSystem - 18 FileSystem - 19 Figure 8 ■ The I-node, showing How I-node Block Pointers Are Used to Locate the Blocks in a File FileSystem - 20 FileSystem - 21 Figure 10 ■ Kernel Operations for Following the Pathname ../a/b FileSystem - 22 * File Operations: 1) create - find spce on disk for the file. - insert the directory entry, records the name of the file and the location in the file system. 2) open - the open operation takes a file name, searches the directory, copying the directory entry into the table (in memory) of open files; then, OS returns an pointer to the entry in the table of open files, avoiding any further searching. 3) write - input: the file name + data. - according to the file name, find the directory entry. - the directory entry will need to store a pointer to the current block of the file. (write pointer) 4) read 5) reset 6) delete 7) link 8) unlink. (only when the number of linked file names = 0) * To avoid to search the directory entry again, when a file operation is requested, an index into to this table is used (returned), so no searching is required. FileSystem - 23 * Disk space management: page/segment - block size. - keep track of free blocks. - disk quotas of each user. * File system reliability: backup, recovery, consistency (concurrency control). * Security and Protection - (owner, group, universal) + (rwx) -rwxrwxrwx (777) FileSystem - 24 * Mount FileSystem - 25 * Managing your Files ( utilities for file management ) -pwd, cd, ls, rm, mv, cp. -ln : create links. It creates a new name which references the original file. Only one copy exists although it has two names. a) hard links (traditional forms). -Ex. In old new. Those two files have the same I-node number. -Two problems: (1) They only work within a file system because they are based on I-node. (2) They can be very transitory because they operate at such a low level in the UNIX file system. b) symbolic links. -Ex. Ln –s old new. -A symbolic link operates at a higher level then a hard link because a symbolic link refers to a file by name, not through the I-node table.
Load more

Recommended publications
  • Fundamentals of UNIX Lab 5.4.6 – Listing Directory Information (Estimated Time: 30 Min.)
    Fundamentals of UNIX Lab 5.4.6 – Listing Directory Information (Estimated time: 30 min.) Objectives: • Learn to display directory and file information • Use the ls (list files) command with various options • Display hidden files • Display files and file types • Examine and interpret the results of a long file listing • List individual directories • List directories recursively Background: In this lab, the student will use the ls command, which is used to display the contents of a directory. This command will display a listing of all files and directories within the current directory or specified directory or directories. If no pathname is given as an argument, ls will display the contents of the current directory. The ls command will list any subdirectories and files that are in the current working directory if a pathname is specified. The ls command will also default to a wide listing and display only file and directory names. There are many options that can be used with the ls command, which makes this command one of the more flexible and useful UNIX commands. Command Format: ls [-option(s)] [pathname[s]] Tools / Preparation: a) Before starting this lab, the student should review Chapter 5, Section 4 – Listing Directory Contents b) The student will need the following: 1. A login user ID, for example user2, and a password assigned by their instructor. 2. A computer running the UNIX operating system with CDE. 3. Networked computers in classroom. Notes: 1 - 5 Fundamentals UNIX 2.0—-Lab 5.4.6 Copyright 2002, Cisco Systems, Inc. Use the diagram of the sample Class File system directory tree to assist with this lab.
    [Show full text]
  • Copy on Write Based File Systems Performance Analysis and Implementation
    Copy On Write Based File Systems Performance Analysis And Implementation Sakis Kasampalis Kongens Lyngby 2010 IMM-MSC-2010-63 Technical University of Denmark Department Of Informatics Building 321, DK-2800 Kongens Lyngby, Denmark Phone +45 45253351, Fax +45 45882673 [email protected] www.imm.dtu.dk Abstract In this work I am focusing on Copy On Write based file systems. Copy On Write is used on modern file systems for providing (1) metadata and data consistency using transactional semantics, (2) cheap and instant backups using snapshots and clones. This thesis is divided into two main parts. The first part focuses on the design and performance of Copy On Write based file systems. Recent efforts aiming at creating a Copy On Write based file system are ZFS, Btrfs, ext3cow, Hammer, and LLFS. My work focuses only on ZFS and Btrfs, since they support the most advanced features. The main goals of ZFS and Btrfs are to offer a scalable, fault tolerant, and easy to administrate file system. I evaluate the performance and scalability of ZFS and Btrfs. The evaluation includes studying their design and testing their performance and scalability against a set of recommended file system benchmarks. Most computers are already based on multi-core and multiple processor architec- tures. Because of that, the need for using concurrent programming models has increased. Transactions can be very helpful for supporting concurrent program- ming models, which ensure that system updates are consistent. Unfortunately, the majority of operating systems and file systems either do not support trans- actions at all, or they simply do not expose them to the users.
    [Show full text]
  • Administering Unidata on UNIX Platforms
    C:\Program Files\Adobe\FrameMaker8\UniData 7.2\7.2rebranded\ADMINUNIX\ADMINUNIXTITLE.fm March 5, 2010 1:34 pm Beta Beta Beta Beta Beta Beta Beta Beta Beta Beta Beta Beta Beta Beta Beta Beta UniData Administering UniData on UNIX Platforms UDT-720-ADMU-1 C:\Program Files\Adobe\FrameMaker8\UniData 7.2\7.2rebranded\ADMINUNIX\ADMINUNIXTITLE.fm March 5, 2010 1:34 pm Beta Beta Beta Beta Beta Beta Beta Beta Beta Beta Beta Beta Beta Notices Edition Publication date: July, 2008 Book number: UDT-720-ADMU-1 Product version: UniData 7.2 Copyright © Rocket Software, Inc. 1988-2010. All Rights Reserved. Trademarks The following trademarks appear in this publication: Trademark Trademark Owner Rocket Software™ Rocket Software, Inc. Dynamic Connect® Rocket Software, Inc. RedBack® Rocket Software, Inc. SystemBuilder™ Rocket Software, Inc. UniData® Rocket Software, Inc. UniVerse™ Rocket Software, Inc. U2™ Rocket Software, Inc. U2.NET™ Rocket Software, Inc. U2 Web Development Environment™ Rocket Software, Inc. wIntegrate® Rocket Software, Inc. Microsoft® .NET Microsoft Corporation Microsoft® Office Excel®, Outlook®, Word Microsoft Corporation Windows® Microsoft Corporation Windows® 7 Microsoft Corporation Windows Vista® Microsoft Corporation Java™ and all Java-based trademarks and logos Sun Microsystems, Inc. UNIX® X/Open Company Limited ii SB/XA Getting Started The above trademarks are property of the specified companies in the United States, other countries, or both. All other products or services mentioned in this document may be covered by the trademarks, service marks, or product names as designated by the companies who own or market them. License agreement This software and the associated documentation are proprietary and confidential to Rocket Software, Inc., are furnished under license, and may be used and copied only in accordance with the terms of such license and with the inclusion of the copyright notice.
    [Show full text]
  • System Calls System Calls
    System calls We will investigate several issues related to system calls. Read chapter 12 of the book Linux system call categories file management process management error handling note that these categories are loosely defined and much is behind included, e.g. communication. Why? 1 System calls File management system call hierarchy you may not see some topics as part of “file management”, e.g., sockets 2 System calls Process management system call hierarchy 3 System calls Error handling hierarchy 4 Error Handling Anything can fail! System calls are no exception Try to read a file that does not exist! Error number: errno every process contains a global variable errno errno is set to 0 when process is created when error occurs errno is set to a specific code associated with the error cause trying to open file that does not exist sets errno to 2 5 Error Handling error constants are defined in errno.h here are the first few of errno.h on OS X 10.6.4 #define EPERM 1 /* Operation not permitted */ #define ENOENT 2 /* No such file or directory */ #define ESRCH 3 /* No such process */ #define EINTR 4 /* Interrupted system call */ #define EIO 5 /* Input/output error */ #define ENXIO 6 /* Device not configured */ #define E2BIG 7 /* Argument list too long */ #define ENOEXEC 8 /* Exec format error */ #define EBADF 9 /* Bad file descriptor */ #define ECHILD 10 /* No child processes */ #define EDEADLK 11 /* Resource deadlock avoided */ 6 Error Handling common mistake for displaying errno from Linux errno man page: 7 Error Handling Description of the perror () system call.
    [Show full text]
  • Serverless Network File Systems
    Serverless Network File Systems Thomas E. Anderson, Michael D. Dahlin, Jeanna M. Neefe, David A. Patterson, Drew S. Roselli, and Randolph Y. Wang Computer Science Division University of California at Berkeley Abstract In this paper, we propose a new paradigm for network file system design, serverless network file systems. While traditional network file systems rely on a central server machine, a serverless system utilizes workstations cooperating as peers to provide all file system services. Any machine in the system can store, cache, or control any block of data. Our approach uses this location independence, in combination with fast local area networks, to provide better performance and scalability than traditional file systems. Further, because any machine in the system can assume the responsibilities of a failed component, our serverless design also provides high availability via redundant data storage. To demonstrate our approach, we have implemented a prototype serverless network file system called xFS. Preliminary performance measurements suggest that our architecture achieves its goal of scalability. For instance, in a 32-node xFS system with 32 active clients, each client receives nearly as much read or write throughput as it would see if it were the only active client. 1. Introduction A serverless network file system distributes storage, cache, and control over cooperating workstations. This approach contrasts with traditional file systems such as Netware [Majo94], NFS [Sand85], Andrew [Howa88], and Sprite [Nels88] where a central server machine stores all data and satisfies all client cache misses. Such a central server is both a performance and reliability bottleneck. A serverless system, on the other hand, distributes control processing and data storage to achieve scalable high performance, migrates the responsibilities of failed components to the remaining machines to provide high availability, and scales gracefully to simplify system management.
    [Show full text]
  • A Brief History of UNIX File Systems
    A Brief History of UNIX File Systems Val Henson IBM, Inc. [email protected] Summary • Review of UNIX file system concepts • File system formats, 1974-2004 • File system comparisons and recommendations • Fun trivia • Questions and answers (corrections ONLY during talk) 1 VFS/vnode architecture • VFS: Virtual File System: common object-oriented interface to fs's • vnode: virtual node: abstract file object, includes vnode ops • All operations to fs's and files done through VFS/vnode in- terface • S.R. Kleiman, \Vnodes: An Architecture for Multiple File System Types in Sun UNIX," Summer USENIX 1986 2 Some Definitions superblock: fs summary, pointers to other information inode: on-disk structure containing information about a file indirect block: block containing pointers to other blocks metadata: everything that is not user data, including directory entries 3 Disk characteristics • Track - contiguous region, can be read at maximum speed • Seek time - time to move the head between different tracks • Rotational delay - time for part of track to move under head • Fixed per I/O overhead means bigger I/Os are better 4 In the beginning: System V FS (S5FS) (c. 1974) • First UNIX file system, referred to as \FS" • Disk layout: superblock, inodes, followed by everything else • 512-1024 byte block size, no fragments • Super simple - and super slow! 2-5% of raw disk bandwidth 5 Berkeley Fast File System (FFS or UFS) (c. 1984) • Metadata spread throughout the disk in \cylinder groups" • Block size 4KB minimum, frag size 1KB (to avoid 45% wasted space) • Physical
    [Show full text]
  • Ext4 File System and Crash Consistency
    1 Ext4 file system and crash consistency Changwoo Min 2 Summary of last lectures • Tools: building, exploring, and debugging Linux kernel • Core kernel infrastructure • Process management & scheduling • Interrupt & interrupt handler • Kernel synchronization • Memory management • Virtual file system • Page cache and page fault 3 Today: ext4 file system and crash consistency • File system in Linux kernel • Design considerations of a file system • History of file system • On-disk structure of Ext4 • File operations • Crash consistency 4 File system in Linux kernel User space application (ex: cp) User-space Syscalls: open, read, write, etc. Kernel-space VFS: Virtual File System Filesystems ext4 FAT32 JFFS2 Block layer Hardware Embedded Hard disk USB drive flash 5 What is a file system fundamentally? int main(int argc, char *argv[]) { int fd; char buffer[4096]; struct stat_buf; DIR *dir; struct dirent *entry; /* 1. Path name -> inode mapping */ fd = open("/home/lkp/hello.c" , O_RDONLY); /* 2. File offset -> disk block address mapping */ pread(fd, buffer, sizeof(buffer), 0); /* 3. File meta data operation */ fstat(fd, &stat_buf); printf("file size = %d\n", stat_buf.st_size); /* 4. Directory operation */ dir = opendir("/home"); entry = readdir(dir); printf("dir = %s\n", entry->d_name); return 0; } 6 Why do we care EXT4 file system? • Most widely-deployed file system • Default file system of major Linux distributions • File system used in Google data center • Default file system of Android kernel • Follows the traditional file system design 7 History of file system design 8 UFS (Unix File System) • The original UNIX file system • Design by Dennis Ritche and Ken Thompson (1974) • The first Linux file system (ext) and Minix FS has a similar layout 9 UFS (Unix File System) • Performance problem of UFS (and the first Linux file system) • Especially, long seek time between an inode and data block 10 FFS (Fast File System) • The file system of BSD UNIX • Designed by Marshall Kirk McKusick, et al.
    [Show full text]
  • 11.7 the Windows 2000 File System
    830 CASE STUDY 2: WINDOWS 2000 CHAP. 11 11.7 THE WINDOWS 2000 FILE SYSTEM Windows 2000 supports several file systems, the most important of which are FAT-16, FAT-32, and NTFS (NT File System). FAT-16 is the old MS-DOS file system. It uses 16-bit disk addresses, which limits it to disk partitions no larger than 2 GB. FAT-32 uses 32-bit disk addresses and supports disk partitions up to 2 TB. NTFS is a new file system developed specifically for Windows NT and car- ried over to Windows 2000. It uses 64-bit disk addresses and can (theoretically) support disk partitions up to 264 bytes, although other considerations limit it to smaller sizes. Windows 2000 also supports read-only file systems for CD-ROMs and DVDs. It is possible (even common) to have the same running system have access to multiple file system types available at the same time. In this chapter we will treat the NTFS file system because it is a modern file system unencumbered by the need to be fully compatible with the MS-DOS file system, which was based on the CP/M file system designed for 8-inch floppy disks more than 20 years ago. Times have changed and 8-inch floppy disks are not quite state of the art any more. Neither are their file systems. Also, NTFS differs both in user interface and implementation in a number of ways from the UNIX file system, which makes it a good second example to study. NTFS is a large and complex system and space limitations prevent us from covering all of its features, but the material presented below should give a reasonable impression of it.
    [Show full text]
  • Chapter 11: File System Implementation! Chapter 11: File System Implementation!
    The image cannot be displayed. Your computer may not have enough memory to open the image, or the image may have been corrupted. Restart your computer, and then open the file again. If the red x still appears, you may have to delete the image and then insert it again. Chapter 11: File System Implementation! Chapter 11: File System Implementation! ■ File-System Structure" ■! File-System Implementation " ■! Directory Implementation" ■! Allocation Methods" ■! Free-Space Management " ■! Efficiency and Performance" ■! Recovery" ■! Log-Structured File Systems" ■! NFS" ■! Example: WAFL File System" Operating System Concepts! 11.2! Silberschatz, Galvin and Gagne ©2005! Objectives! ■! To describe the details of implementing local file systems and directory structures" ■! To describe the implementation of remote file systems" ■! To discuss block allocation and free-block algorithms and trade-offs" Operating System Concepts! 11.3! Silberschatz, Galvin and Gagne ©2005! User program & Kernel interface in Linux! Note: This picture is excerpted from Write a Linux Hardware Device Driver, Andrew O’Shauqhnessy, Unix world Operating System Concepts! 11.4! Silberschatz, Galvin and Gagne ©2005! File-System Structure! ■! File structure" ●! Logical storage unit" ●! Collection of related information" ■! File system resides on secondary storage (disks or SSD)" ■! File system organized into layers" ■! File control block – storage structure consisting of information about a file" Operating System Concepts! 11.5! Silberschatz, Galvin and Gagne ©2005! Layered File System!
    [Show full text]
  • File Systems
    File Systems Profs. Bracy and Van Renesse based on slides by Prof. Sirer Storing Information • Applications could store information in the process address space • Why is this a bad idea? – Size is limited to size of virtual address space – The data is lost when the application terminates • Even when computer doesn’t crash! – Multiple process might want to access the same data File Systems • 3 criteria for long-term information storage: 1. Able to store very large amount of information 2. Information must survive the processes using it 3. Provide concurrent access to multiple processes • Solution: – Store information on disks in units called files – Files are persistent, only owner can delete it – Files are managed by the OS File Systems: How the OS manages files! File Naming • Motivation: Files abstract information stored on disk – You do not need to remember block, sector, … – We have human readable names • How does it work? – Process creates a file, and gives it a name • Other processes can access the file by that name – Naming conventions are OS dependent • Usually names as long as 255 characters is allowed • Windows names not case sensitive, UNIX family is File Extensions • Name divided into 2 parts: Name+Extension • On UNIX, extensions are not enforced by OS – Some applications might insist upon them • Think: .c, .h, .o, .s, etc. for C compiler • Windows attaches meaning to extensions – Tries to associate applications to file extensions File Access • Sequential access – read all bytes/records from the beginning – particularly convenient for magnetic tape • Random access – bytes/records read in any order – essential for database systems File Attributes • File-specific info maintained by the OS – File size, modification date, creation time, etc.
    [Show full text]
  • Filesystems HOWTO Filesystems HOWTO Table of Contents Filesystems HOWTO
    Filesystems HOWTO Filesystems HOWTO Table of Contents Filesystems HOWTO..........................................................................................................................................1 Martin Hinner < [email protected]>, http://martin.hinner.info............................................................1 1. Introduction..........................................................................................................................................1 2. Volumes...............................................................................................................................................1 3. DOS FAT 12/16/32, VFAT.................................................................................................................2 4. High Performance FileSystem (HPFS)................................................................................................2 5. New Technology FileSystem (NTFS).................................................................................................2 6. Extended filesystems (Ext, Ext2, Ext3)...............................................................................................2 7. Macintosh Hierarchical Filesystem − HFS..........................................................................................3 8. ISO 9660 − CD−ROM filesystem.......................................................................................................3 9. Other filesystems.................................................................................................................................3
    [Show full text]
  • Chapter 15: File System Internals
    Chapter 15: File System Internals Operating System Concepts – 10th dition Silberschatz, Galvin and Gagne ©2018 Chapter 15: File System Internals File Systems File-System Mounting Partitions and Mounting File Sharing Virtual File Systems Remote File Systems Consistency Semantics NFS Operating System Concepts – 10th dition 1!"2 Silberschatz, Galvin and Gagne ©2018 Objectives Delve into the details of file systems and their implementation Explore "ooting and file sharing Describe remote file systems, using NFS as an example Operating System Concepts – 10th dition 1!"# Silberschatz, Galvin and Gagne ©2018 File System $eneral-purpose computers can have multiple storage devices Devices can "e sliced into partitions, %hich hold volumes Volumes can span multiple partitions Each volume usually formatted into a file system # of file systems varies, typically dozens available to choose from Typical storage device organization) Operating System Concepts – 10th dition 1!"$ Silberschatz, Galvin and Gagne ©2018 Example Mount Points and File Systems - Solaris Operating System Concepts – 10th dition 1!"! Silberschatz, Galvin and Gagne ©2018 Partitions and Mounting Partition can be a volume containing a file system +* cooked-) or ra& – just a sequence of "loc,s %ith no file system Boot bloc, can point to boot volume or "oot loader set of "loc,s that contain enough code to ,now how to load the ,ernel from the file system 3r a boot management program for multi-os booting 'oot partition contains the 3S, other partitions can hold other
    [Show full text]