DOCSLIB.ORG

Files Viewed on Different OS’S? • What Is a File System from the Programmer’S Viewpoint? – You Mostly Know This, but We’Ll Review the Main Points

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Files Viewed on Different OS’S? • What Is a File System from the Programmer’S Viewpoint? – You Mostly Know This, but We’Ll Review the Main Points File Systems Chapter 4 1 What do we need to know? • How are files viewed on different OS’s? • What is a file system from the programmer’s viewpoint? – You mostly know this, but we’ll review the main points. • How are file systems put together? – How is the disk laid out for directories? For files? What kind of memory structures are needed? • What do some real file systems look like? – cp/m, ms-dos (fat-12/16/32), ntfs, nfs, ext2, … • What directions are file systems going? 2 1 Long-term Information Storage 1. Must store large amounts of data 2. Information stored must survive the termination of the process using it 3. Multiple processes must be able to access the information concurrently 3 File Naming Issues • Character Set • Length • Extensions 4 2 File Naming Typical file extensions. 5 File Structure There are lots of files types. Here are three: – byte sequence, record sequence, tree 6 3 Sample Files (a) An executable file (b) An archive 7 File Access • Sequential access – read all bytes/records from the beginning – cannot jump around, could rewind or back up – convenient when medium was mag tape • Random access – bytes/records read in any order – essential for data base systems – read can be … • move file marker (seek), then read or … • read and then move file marker 8 4 File Attributes Possible file attributes 9 File Operations 1. Create 7. Append 2. Delete 8. Seek 3. Open 9. Get attributes 4. Close 10. Set Attributes 5. Read 11. Rename 6. Write 10 5 An Example Program Using Unix File System Calls (1/2) 11 An Example Program Using File System Calls (2/2) 12 6 Memory-Mapped Files (a) Segmented process before mapping files into its address space (b) Process after mapping existing file abc into one segment creating new segment for xyz 13 Directories Single-Level Directory Systems • A single level directory system – contains 4 files – owned by 3 different people, A, B, and C 14 7 Two-level Directory Systems Letters indicate owners of the directories and files 15 Hierarchical Directory Systems A hierarchical directory system 16 8 Directory Operations 1. Create 5. Readdir 2. Delete 6. Rename 3. Opendir 7. Link 4. Closedir 8. Unlink 17 File System Implementation A possible file system layout 18 9 Implementing Files (1) (a) Contiguous allocation of disk space for 7 files (b) State of the disk after files D and E have been removed 19 Implementing Files (2) Storing a file as a linked list of disk blocks 20 10 Implementing Files (3) File Allocation Table (FAT) uses a linked list in memory 21 Implementing Files (4) Combination of Direct and Indirect Block Pointers Note: This is a simplified version of Unix i-node 22 11 The UNIX V7 File System A UNIX i-node 23 Implementing Directories (1) (a) A simple directory fixed size entries disk addresses and attributes in directory entry (b) Directory in which each entry just refers to an i-node 24 12 Implementing Directories (2) • Two ways of handling long file names in directory – (a) In-line – (b) In a heap 25 Linking (1) File system containing a file that is “shared” between two directories 26 13 Links (2) (a) Situation prior to linking (b) After the link is created (c) After the original owner removes the file 27 Disk Space Management (1) Block size • Dark line (left hand scale) gives data rate of a disk • Dotted line (right hand scale) gives disk space efficiency • All files here are 2KB 28 14 Disk Space Management (2) (a) Storing the free list on a linked list (b) A bit map 29 File System Checking • Possible results while running fsck (a) consistent (b) missing block (c) duplicate block in free list (d) duplicate data block 30 15 File System Performance (1) The block cache data structures 31 File System Writes • Unix – “Critical Blocks” are written immediately – Data blocks are written periodically or when the block is removed from the block cache • MSDOS – Uses “Write-through cache”. All writes are immediate. 32 16 Read Ahead • When block N is requested, the file system can issue a read for block N+1 also. • What if the file is not being read sequentially? – Initially assume it is, but monitor disk access and set a flag to non-sequential if needed. This can be used to disable read ahead. 33 File System Performance (2) • I-nodes placed at the start of the disk • Disk divided into cylinder groups – each with its own blocks and i-nodes 34 17 Log-Structured File Systems • With CPUs faster, memory larger – disk caches can also be larger – increasing number of read requests can come from cache – thus, most disk accesses will be writes • LSF Strategy structures entire disk as a log – have all writes initially buffered in memory – periodically write these to the end of the disk log – when file opened, locate i-node, then find blocks 35 Journaling • What happens when you remove a file? – Remove the directory entry – Release the i-node – Free the disk blocks • What happens if there is a crash after the first or second steps? • How can you minimize the damage? 36 18 The CP/M File System (1) Memory layout of CP/M 37 The CP/M File System (2) The CP/M directory entry format 38 19 File Allocation Table (FAT) Partition Layout • Partion layout: – Boot block – FAT – FAT copy – Root directory • In FAT-12 and FAT-16, preassigned enough space for 256 directory entries – Other directories and files 39 FAT Table Sizes • FAT-12 – 212 clusters – Cluster Size: 512 Byte to 8KB – Partitions size up to 32MB (4K clusters * 8KB / cluster) – Windows default for volumes < 16MB, such as floppies • FAT-16 – 216 clusters – Cluster Size: 512 Byte to 64KB – Partitions size up to 4GB (64K clusters * 64KB / cluster) • FAT-32 – 228 clusters – Cluster Size: 512 Byte to 32KB – Partitions size in principle up to 8TB, but Windows will only create FAT-32 partitions up to 32GB. • Note that all FAT systems reserve the first two and last sixteen clusters in a partition, so actual partition sizes are slightly smaller than listed above. 40 20 Directory Entries Original MS-DOS directory entry: Directory entry used in Windows: Bytes 41 The Windows 98 File System An example of how a long name is stored in Windows 98 42 21 UNIX File System Disk layout in classical UNIX systems 43 The UNIX File System A UNIX V7 directory entry (old) 44 22 The UNIX V7 File System A UNIX i-node 45 UNIX File System Directory entry fields. Attributes in the i-node 46 23 The UNIX File System Path Names 47 The UNIX File System Some important directories found in most UNIX systems 48 24 Pathnames • Absolute Pathname – Begins at the root directory : / – Contains all sub-directory names separated by slashes – Filename – ~jsterling • ~ is recognized as a short-cut for the absolute path to the home directory. • Relative Pathname – Does not begin with the root directory. – Starts in the current working directory. Sometimes the current working directory is shown explicitly using: . – May move up the file tree using .. to refer to a parent directory. 49 The UNIX File System The steps in looking up /usr/ast/mbox 50 25 The UNIX File System • Before linking. • After linking. (a) Before linking. (b) After linking Note that hard links Note that soft links (aka symbolic links) • must refer to other files in the same file system. • contain only a pathname. • are not permitted to refer to directories. • result in a “dangling pointer” if the original • are indistinguishable from the original file name. filename is deleted. 51 The UNIX File System • Separate file systems • After mounting (a) (b) (a) Before mounting. (b) After mounting 52 26 UNIX File System (3) The relation between the file descriptor table, the open file description and the i-node 53 The Linux File System • Super block: – # of inodes, # of blocks, etc. • Group Descriptor: – # of free i-nodes, # of free blocks, # of directories • Bitmaps: – Each is one block long 54 27 Record Locking in Unix • Can lock any range of bytes in a file • Can be multiple locks overlapping on a file • Locks can be – Exclusive (write): No other process can have a lock on the range. – Shared (read): Other locks may exist on the same bytes. • A failed lock can be made to block or not (choice of system call). • A process’s locks are released when a) The process terminates b) The process closes the file. Even if the process had it open more than once simultaneously! • Locks are not inherited across fork. • Locks can carry across exec. • Deadlock possibility: – Competing locks could in principle result in deadlock, – but this is prevented in Unix. 55 System Calls for File Management • s is an error code • fd is a file descriptor • position is a file offset 56 28 The stat System Call • Mode: includes type and protection • Inode # • Device • Link count • Owner’s ID • Group ID • File Size in bytes • Access Time • Modification Time • Status change Time • Blocksize • Block count (512 byte blocks) Note that not all fields are stored in the i-nodes, themselves. From Solaris Man Page 57 System Calls for Directory Management • s is an error code • dir identifies a directory stream • dirent is a directory entry 58 29 UNIX File System (4) • A BSD directory with three files • The same directory after the file voluminous has been removed 59 Unix File Protection • Divide the world into categories (owner / group / world) and specifying read / write / execute access for each.
Load more

Recommended publications
  • 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]
  • 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]
  • Cygwin User's Guide
    Cygwin User’s Guide Cygwin User’s Guide ii Copyright © Cygwin authors Permission is granted to make and distribute verbatim copies of this documentation provided the copyright notice and this per- mission notice are preserved on all copies. Permission is granted to copy and distribute modified versions of this documentation under the conditions for verbatim copying, provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one. Permission is granted to copy and distribute translations of this documentation into another language, under the above conditions for modified versions, except that this permission notice may be stated in a translation approved by the Free Software Foundation. Cygwin User’s Guide iii Contents 1 Cygwin Overview 1 1.1 What is it? . .1 1.2 Quick Start Guide for those more experienced with Windows . .1 1.3 Quick Start Guide for those more experienced with UNIX . .1 1.4 Are the Cygwin tools free software? . .2 1.5 A brief history of the Cygwin project . .2 1.6 Highlights of Cygwin Functionality . .3 1.6.1 Introduction . .3 1.6.2 Permissions and Security . .3 1.6.3 File Access . .3 1.6.4 Text Mode vs. Binary Mode . .4 1.6.5 ANSI C Library . .4 1.6.6 Process Creation . .5 1.6.6.1 Problems with process creation . .5 1.6.7 Signals . .6 1.6.8 Sockets . .6 1.6.9 Select . .7 1.7 What’s new and what changed in Cygwin . .7 1.7.1 What’s new and what changed in 3.2 .
    [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]
  • Secure Untrusted Data Repository (SUNDR)
    Secure Untrusted Data Repository (SUNDR) Jinyuan Li, Maxwell Krohn,∗ David Mazieres,` and Dennis Shasha NYU Department of Computer Science Abstract for over 20,000 different software packages. Many of these packages are bundled with various operating sys- SUNDR is a network file system designed to store data tem distributions, often without a meaningful audit. By securely on untrusted servers. SUNDR lets clients de- compromising sourceforge, an attacker can therefore in- tect any attempts at unauthorized file modification by troduce subtle vulnerabilities in software that may even- malicious server operators or users. SUNDR’s protocol tually run on thousands or even millions of machines. achieves a property called fork consistency, which guar- Such concerns are no mere academic exercise. For ex- antees that clients can detect any integrity or consistency ample, the Debian GNU/Linux development cluster was failures as long as they see each other’s file modifications. compromised in 2003 [2]. An unauthorized attacker used An implementation is described that performs compara- a sniffed password and a kernel vulnerability to gain su- bly with NFS (sometimes better and sometimes worse), peruser access to Debian’s primary CVS and Web servers. while offering significantly stronger security. After detecting the break-in, administrators were forced to freeze development for several days, as they employed manual and ad-hoc sanity checks to assess the extent of 1 Introduction the damage. Similar attacks have also succeeded against Apache [1], Gnome [32], and other popular projects. SUNDR is a network file system that addresses a long- Rather than hope for invulnerable servers, we have de- standing tension between data integrity and accessibility.
    [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]
  • File-System Implementation
    CHAPTER File-System 11 Implementation As we saw in Chapter 10, the ®le system provides the mechanism for on-line storage and access to ®le contents, including data and programs. The ®le system resides permanently on secondary storage, which is designed to hold a large amount of data permanently. This chapter is primarily concerned with issues surrounding ®le storage and access on the most common secondary-storage medium, the disk. We explore ways to structure ®le use, to allocate disk space, to recover freed space, to track the locations of data, and to interface other parts of the operating system to secondary storage. Performance issues are considered throughout the chapter. Bibliographical Notes The MS-DOS FAT system is explained in[Norton and Wilton (1988)]. The internals of the BSD UNIX system are covered in full in[McKusick and Neville- Neil (2005)]. Details concerning ®le systems for Linux can be found in[Love (2010)]. The Google ®le system is described in[Ghemawat et al. (2003)]. FUSE can be found at http://fuse.sourceforge.net. Log-structured ®le organizations for enhancing both performance and consistency are discussed in[Rosenblum and Ousterhout (1991)], [Seltzer et al. (1993)], and[Seltzer et al. (1995)]. Algorithms such as balanced trees (and much more) are covered by[Knuth (1998)] and [Cormen et al. (2009)].[Silvers (2000)] discusses implementing the page cache in the NetBSD operating system. The ZFS source code for space maps can be found at http://src.opensolaris.org/source/xref/onnv/onnv- gate/usr/src/uts/common/fs/zfs/space map.c. The network ®le system (NFS) is discussed in[Callaghan (2000)].
    [Show full text]
  • Comparative Analysis of Distributed and Parallel File Systems' Internal Techniques
    Comparative Analysis of Distributed and Parallel File Systems’ Internal Techniques Viacheslav Dubeyko Content 1 TERMINOLOGY AND ABBREVIATIONS ................................................................................ 4 2 INTRODUCTION......................................................................................................................... 5 3 COMPARATIVE ANALYSIS METHODOLOGY ....................................................................... 5 4 FILE SYSTEM FEATURES CLASSIFICATION ........................................................................ 5 4.1 Distributed File Systems ............................................................................................................................ 6 4.1.1 HDFS ..................................................................................................................................................... 6 4.1.2 GFS (Google File System) ....................................................................................................................... 7 4.1.3 InterMezzo ............................................................................................................................................ 9 4.1.4 CodA .................................................................................................................................................... 10 4.1.5 Ceph.................................................................................................................................................... 12 4.1.6 DDFS ..................................................................................................................................................
    [Show full text]