DOCSLIB.ORG

Chapter 12: File System Implementation

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Chapter 12: File System Implementation This chapter is concerned with the details associated with file systems residing on secondary storage. Specific implementation issues are explored using the disk as the secondary storage device. I File System Structure I File System Implementation I Directory Implementation I Allocation Methods I Free-Space Management I Efficiency and Performance I Recovery I Log-Structured File Systems I NFS Operating System Concepts 12.1 Silberschatz, Galvin and Gagne 2002 File-System Structure Pertinent Disk Details I The physical unit of transfer is a disk sector (e.g., 512 bytes). I Sectors can be written in place. I Any given sector can be accessed directly. I The OS imposes a file system for efficient and convenient access to the disk. I The file system design deals with two distinct matters: 1. How should the file system look to the user. 2. Creating data structures and algorithms to map the logical file system onto the physical secondary- storage device. Operating System Concepts 12.2 Silberschatz, Galvin and Gagne 2002 Blocks and Fragments [4.2BSD] I Logical transfer of data is in blocks. I Blocks are “chunks” or clusters of disk sectors. I block size decision:: {a time space tradeoff} ! Uses two sizes block and fragment ! E.g. 4KB block; 1KB fragment Operating System Concepts 12.3 Silberschatz, Galvin and Gagne 2002 Layered File System A layered design abstraction I I/O control :: device drivers and interrupt service routines that perform the actual block transfers. I Basic file system :: issues generic low-level commands to device drivers. I File organization :: translates logical block addresses to physical block addresses. I Logical file system :: handles metadata that includes file- system structure (e.g., directory structure and file control blocks (FCB’s). Operating System Concepts 12.4 Silberschatz, Galvin and Gagne 2002 In-Memory File System Structures On-disk and in-memory structures are needed to implement a file system: On disk:: 1. Boot control block: needed to boot OS from a disk partition. 2. Partition control block: holds details about partition (e.g., blocks in partition, free- block count, …) superblock [UNIX],Master File Table [NTFS] 3. Directory structure: to organize files. 4. FCB (or inode) : Operating System Concepts 12.5 Silberschatz, Galvin and Gagne 2002 A Typical File Control Block [Linux] inode is the term for FCB Operating System Concepts 12.6 Silberschatz, Galvin and Gagne 2002 In-Memory File System Structures On-disk and in-memory structures needed to implement a file system: In-memory:: 1. Per-process open-file table 2. System-wide open-file table 3. In-memory directory structure 4. In-memory partition table ☛ In some OS’s file system scheme used as interface to other system aspects. [Unix uses system-wide open table for networking - e.g.,socket descriptors.] ☛ Caching used extensively – namely, all the information about an open file is in memory except actual data blocks. Operating System Concepts 12.7 Silberschatz, Galvin and Gagne 2002 In-Memory File System Structures (a) Open operation (b) Read operation Operating System Concepts 12.8 Silberschatz, Galvin and Gagne 2002 File System Implementation File Structure Disk Space Open File User Space Table Table Data block read (4, …) Read (4,…) Inode list (per process) In-core inode Modified Claypool Figure list [Figure A.7 page 837] Operating System Concepts 12.9 Silberschatz, Galvin and Gagne 2002 Virtual File Systems I Virtual File Systems (VFS) provide an object-oriented way of implementing file systems. I VFS allows the same system call interface (the API) to be used for different types of file systems. I The API is to the VFS interface, rather than any specific type of file system. I VFS provides a mechanism for integrating NFS into the OS. Operating System Concepts 12.10 Silberschatz, Galvin and Gagne 2002 Schematic View of Virtual File System Operating System Concepts 12.11 Silberschatz, Galvin and Gagne 2002 Directory Implementation I Linear list of file names with pointer to the data blocks. ✦ simple to program ✦ time-consuming to execute due to linear search I Hash Table – linear list with hash data structure. ✦ decreases directory search time ✦ collisions – situations where two file names hash to the same location ✦ fixed size {disadvantage: hash function is dependent on fixed size} Operating System Concepts 12.12 Silberschatz, Galvin and Gagne 2002 File System Implementation I Which blocks with which file? I File descriptor implementations: ✦ Contiguous ✦ Linked List ✦ Linked List with Index ✦ I-nodes File Descriptor Operating System Concepts 12.13 Silberschatz, Galvin and Gagne 2002 Allocation Methods I An allocation method refers to how disk blocks are allocated for files: I Contiguous allocation I Linked allocation I Indexed allocation Operating System Concepts 12.14 Silberschatz, Galvin and Gagne 2002 Contiguous Allocation I Each file occupies a set of contiguous blocks on the disk. I Simple – only starting location (block #) and length (number of blocks) are required. I Random access. I Wasteful of space (dynamic storage-allocation problem). I Files cannot grow. Operating System Concepts 12.15 Silberschatz, Galvin and Gagne 2002 Contiguous Allocation of Disk Space Operating System Concepts 12.16 Silberschatz, Galvin and Gagne 2002 Extent-Based Systems I Many newer file systems (I.e. Veritas File System) use a modified contiguous allocation scheme. I Extent-based file systems allocate disk blocks in extents. I An extent is a contiguous block of disks. Extents are allocated for file allocation. A file consists of one or more extents. Operating System Concepts 12.17 Silberschatz, Galvin and Gagne 2002 Linked Allocation I Each file is a linked list of disk blocks: blocks may be scattered anywhere on the disk. block = pointer Operating System Concepts 12.18 Silberschatz, Galvin and Gagne 2002 Linked Allocation (Cont.) I Simple – need only starting address I Free-space management system – no waste of space I No random access I Mapping Q LA/511 R Block to be accessed is the Qth block in the linked chain of blocks representing the file. Displacement into block = R + 1 File-allocation table (FAT) – disk-space allocation used by MS-DOS and OS/2. Operating System Concepts 12.19 Silberschatz, Galvin and Gagne 2002 Linked Allocation Operating System Concepts 12.20 Silberschatz, Galvin and Gagne 2002 File-Allocation Table Operating System Concepts 12.21 Silberschatz, Galvin and Gagne 2002 Indexed Allocation I Brings all pointers together into the index block. I Logical view. index table Operating System Concepts 12.22 Silberschatz, Galvin and Gagne 2002 Example of Indexed Allocation Operating System Concepts 12.23 Silberschatz, Galvin and Gagne 2002 Indexed Allocation (Cont.) I Need index table I Random access I Dynamic access without external fragmentation, but have overhead of index block. I Mapping from logical to physical in a file of maximum size of 256K words and block size of 512 words. We need only 1 block for index table. Q LA/512 R Q = displacement into index table R = displacement into block Operating System Concepts 12.24 Silberschatz, Galvin and Gagne 2002 Indexed Allocation – Mapping (Cont.) I Mapping from logical to physical in a file of unbounded length (block size of 512 words). I Linked scheme – Link blocks of index table (no limit on size). Q1 LA / (512 x 511) R1 Q1 = block of index table R1 is used as follows: Q2 R1 / 512 R2 Q2 = displacement into block of index table R2 displacement into block of file: Operating System Concepts 12.25 Silberschatz, Galvin and Gagne 2002 Indexed Allocation – Mapping (Cont.) I Two-level index (maximum file size is 5123) Q1 LA / (512 x 512) R1 Q1 = displacement into outer-index R1 is used as follows: Q2 R1 / 512 R2 Q2 = displacement into block of index table R2 displacement into block of file: Operating System Concepts 12.26 Silberschatz, Galvin and Gagne 2002 Indexed Allocation – Mapping (Cont.) Μ outer-index index table file Operating System Concepts 12.27 Silberschatz, Galvin and Gagne 2002 Combined Scheme: UNIX (4K bytes per block) Operating System Concepts 12.28 Silberschatz, Galvin and Gagne 2002 Hierarchical Directory (Unix) Claypool Figure I Tree I Entry: ✦ name ✦ inode number (try “ls –I” or “ls –iad .”) I example: /usr/bob/mbox inode name Operating System Concepts 12.29 Silberschatz, Galvin and Gagne 2002 Unix Directory Example Claypool Figure Root Directory Block 132 Block 406 1 . 6 . I-node 6 I-node 26 26 . 1 .. 1 .. 6 .. 4 bin 26 bob 12 grants 7 dev 17 jeff 81 books 14 lib 14 sue 132 406 60 mbox 9 etc 51 sam 17 Linux 6 usr 29 mark 8 tmp Aha! Looking up I-node 60 Looking up bob gives has contents usr gives Relevant I-node 26 /usr/bob is of mbox I-node 6 data (/usr) in block 406 is in block 132 Operating System Concepts 12.30 Silberschatz, Galvin and Gagne 2002 Unix Disk Layout Boot Sector Superblock Superblocks •Number of inodes •Number of blocks i-nodes •Block number of I-node bit-map block • first data block Data blocks •Max file size •Magic number – identifies cpu Architecture and executable type Operating System Concepts 12.31 Silberschatz, Galvin and Gagne 2002 Free-Space Management I Bit vector (n blocks) 01 2 n-1 … 0 ⇒ block[i] free bit[i] = 678 1 ⇒ block[i] occupied Block number calculation (number of bits per word) * (number of 0-value words) + offset of first 1 bit Operating System Concepts 12.32 Silberschatz, Galvin and Gagne 2002 Free-Space Management (Cont.) I Bit map requires extra space. Example: block size = 212 bytes disk size = 230 bytes (1 gigabyte) n = 230/212 = 218 bits (or 32K bytes) I Easy to get contiguous files I Linked list (free list) ✦ Cannot get contiguous space easily ✦ No waste of space I Grouping I Counting Operating System Concepts 12.33 Silberschatz, Galvin and Gagne 2002 Free-Space Management (Cont.) I Need to protect: ✦ Pointer to free list ✦ Bit map ✔ Must be kept on disk ✔ Copy in memory and disk may differ.
Recommended publications
  • Copy on Write Based File Systems Performance Analysis and Implementation

    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.
  • Oracle® ZFS Storage Appliance Security Guide, Release OS8.6.X

    Oracle® ZFS Storage Appliance Security Guide, Release OS8.6.X

    ® Oracle ZFS Storage Appliance Security Guide, Release OS8.6.x Part No: E76480-01 September 2016 Oracle ZFS Storage Appliance Security Guide, Release OS8.6.x Part No: E76480-01 Copyright © 2014, 2016, Oracle and/or its affiliates. All rights reserved. This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited. The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing. If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, then the following notice is applicable: U.S. GOVERNMENT END USERS. Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.
  • Serverless Network File Systems

    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.
  • A Brief History of UNIX File Systems

    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
  • Enhancing the Accuracy of Synthetic File System Benchmarks Salam Farhat Nova Southeastern University, Salalimo@Gmail.Com

    Enhancing the Accuracy of Synthetic File System Benchmarks Salam Farhat Nova Southeastern University, [email protected]

    Nova Southeastern University NSUWorks CEC Theses and Dissertations College of Engineering and Computing 2017 Enhancing the Accuracy of Synthetic File System Benchmarks Salam Farhat Nova Southeastern University, [email protected] This document is a product of extensive research conducted at the Nova Southeastern University College of Engineering and Computing. For more information on research and degree programs at the NSU College of Engineering and Computing, please click here. Follow this and additional works at: https://nsuworks.nova.edu/gscis_etd Part of the Computer Sciences Commons Share Feedback About This Item NSUWorks Citation Salam Farhat. 2017. Enhancing the Accuracy of Synthetic File System Benchmarks. Doctoral dissertation. Nova Southeastern University. Retrieved from NSUWorks, College of Engineering and Computing. (1003) https://nsuworks.nova.edu/gscis_etd/1003. This Dissertation is brought to you by the College of Engineering and Computing at NSUWorks. It has been accepted for inclusion in CEC Theses and Dissertations by an authorized administrator of NSUWorks. For more information, please contact [email protected]. Enhancing the Accuracy of Synthetic File System Benchmarks by Salam Farhat A dissertation submitted in partial fulfillment of the requirements for the degree of Doctor in Philosophy in Computer Science College of Engineering and Computing Nova Southeastern University 2017 We hereby certify that this dissertation, submitted by Salam Farhat, conforms to acceptable standards and is fully adequate in scope and quality to fulfill the dissertation requirements for the degree of Doctor of Philosophy. _____________________________________________ ________________ Gregory E. Simco, Ph.D. Date Chairperson of Dissertation Committee _____________________________________________ ________________ Sumitra Mukherjee, Ph.D. Date Dissertation Committee Member _____________________________________________ ________________ Francisco J.
  • Ext4 File System and Crash Consistency

    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.
  • 11.7 the Windows 2000 File System

    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.
  • [13주차] Sysfs and Procfs

    [13주차] Sysfs and Procfs

    1 7 Computer Core Practice1: Operating System Week13. sysfs and procfs Jhuyeong Jhin and Injung Hwang Embedded Software Lab. Embedded Software Lab. 2 sysfs 7 • A pseudo file system provided by the Linux kernel. • sysfs exports information about various kernel subsystems, HW devices, and associated device drivers to user space through virtual files. • The mount point of sysfs is usually /sys. • sysfs abstrains devices or kernel subsystems as a kobject. Embedded Software Lab. 3 How to create a file in /sys 7 1. Create and add kobject to the sysfs 2. Declare a variable and struct kobj_attribute – When you declare the kobj_attribute, you should implement the functions “show” and “store” for reading and writing from/to the variable. – One variable is one attribute 3. Create a directory in the sysfs – The directory have attributes as files • When the creation of the directory is completed, the directory and files(attributes) appear in /sys. • Reference: ${KERNEL_SRC_DIR}/include/linux/sysfs.h ${KERNEL_SRC_DIR}/fs/sysfs/* • Example : ${KERNEL_SRC_DIR}/kernel/ksysfs.c Embedded Software Lab. 4 procfs 7 • A special filesystem in Unix-like operating systems. • procfs presents information about processes and other system information in a hierarchical file-like structure. • Typically, it is mapped to a mount point named /proc at boot time. • procfs acts as an interface to internal data structures in the kernel. The process IDs of all processes in the system • Kernel provides a set of functions which are designed to make the operations for the file in /proc : “seq_file interface”. – We will create a file in procfs and print some data from data structure by using this interface.
  • Chapter 11: File System Implementation! Chapter 11: File System Implementation!

    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!
  • Refs: Is It a Game Changer? Presented By: Rick Vanover, Director, Technical Product Marketing & Evangelism, Veeam

    Refs: Is It a Game Changer? Presented By: Rick Vanover, Director, Technical Product Marketing & Evangelism, Veeam

    Technical Brief ReFS: Is It a Game Changer? Presented by: Rick Vanover, Director, Technical Product Marketing & Evangelism, Veeam Sponsored by ReFS: Is It a Game Changer? OVERVIEW Backing up data is more important than ever, as data centers store larger volumes of information and organizations face various threats such as ransomware and other digital risks. Microsoft’s Resilient File System or ReFS offers a more robust solution than the old NT File System. In fact, Microsoft has stated that ReFS is the preferred data volume for Windows Server 2016. ReFS is an ideal solution for backup storage. By utilizing the ReFS BlockClone API, Veeam has developed Fast Clone, a fast, efficient storage backup solution. This solution offers organizations peace of mind through a more advanced approach to synthetic full backups. CONTEXT Rick Vanover discussed Microsoft’s Resilient File System (ReFS) and described how Veeam leverages this technology for its Fast Clone backup functionality. KEY TAKEAWAYS Resilient File System is a Microsoft storage technology that can transform the data center. Resilient File System or ReFS is a valuable Microsoft storage technology for data centers. Some of the key differences between ReFS and the NT File System (NTFS) are: ReFS provides many of the same limits as NTFS, but supports a larger maximum volume size. ReFS and NTFS support the same maximum file name length, maximum path name length, and maximum file size. However, ReFS can handle a maximum volume size of 4.7 zettabytes, compared to NTFS which can only support 256 terabytes. The most common functions are available on both ReFS and NTFS.
  • The Linux Device File-System

    The Linux Device File-System

    The Linux Device File-System Richard Gooch EMC Corporation [email protected] Abstract 1 Introduction All Unix systems provide access to hardware via de- vice drivers. These drivers need to provide entry points for user-space applications and system tools to access the hardware. Following the \everything is a file” philosophy of Unix, these entry points are ex- posed in the file name-space, and are called \device The Device File-System (devfs) provides a power- special files” or \device nodes". ful new device management mechanism for Linux. Unlike other existing and proposed device manage- This paper discusses how these device nodes are cre- ment schemes, it is powerful, flexible, scalable and ated and managed in conventional Unix systems and efficient. the limitations this scheme imposes. An alternative mechanism is then presented. It is an alternative to conventional disc-based char- acter and block special devices. Kernel device drivers can register devices by name rather than de- vice numbers, and these device entries will appear in the file-system automatically. 1.1 Device numbers Devfs provides an immediate benefit to system ad- ministrators, as it implements a device naming scheme which is more convenient for large systems Conventional Unix systems have the concept of a (providing a topology-based name-space) and small \device number". Each instance of a driver and systems (via a device-class based name-space) alike. hardware component is assigned a unique device number. Within the kernel, this device number is Device driver authors can benefit from devfs by used to refer to the hardware and driver instance.
  • Virtual File System (VFS) Implementation in Linux

    Virtual File System (VFS) Implementation in Linux

    Virtual File System (VFS) Implementation in Linux Tushar B. Kute, http://tusharkute.com Virtual File System • The Linux kernel implements the concept of Virtual File System (VFS, originally Virtual Filesystem Switch), so that it is (to a large degree) possible to separate actual "low-level" filesystem code from the rest of the kernel. • This API was designed with things closely related to the ext2 filesystem in mind. For very different filesystems, like NFS, there are all kinds of problems. Virtual File System- Main Objects • The kernel keeps track of files using in-core inodes ("index nodes"), usually derived by the low-level filesystem from on-disk inodes. • A file may have several names, and there is a layer of dentries ("directory entries") that represent pathnames, speeding up the lookup operation. • Several processes may have the same file open for reading or writing, and file structures contain the required information such as the current file position. • Access to a filesystem starts by mounting it. This operation takes a filesystem type (like ext2, vfat, iso9660, nfs) and a device and produces the in-core superblock that contains the information required for operations on the filesystem; a third ingredient, the mount point, specifies what pathname refers to the root of the filesystem. Virtual File System The /proc filesystem • The /proc filesystem contains a illusionary filesystem. • It does not exist on a disk. Instead, the kernel creates it in memory. • It is used to provide information about the system (originally about processes, hence the name). • The proc filesystem is a pseudo-filesystem which provides an interface to kernel data structures.