DOCSLIB.ORG

File Systems

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Mag. iur. Dr. techn. Michael Sonntag File systems Computer Forensics, Budapest 2008 Institute for Information Processing and Microprocessor Technology (FIM) Johannes Kepler University Linz, Austria E-Mail: [email protected] http://www.fim.uni-linz.ac.at/staff/sonntag.htm © Michael Sonntag 2008 Agenda z Physical disk layout z The boot sequence Æ What changes on a disk during a boot? z Filesystems in detail: Æ FAT, FAT32 Æ NTFS Æ EXT3 Michael Sonntag Computer forensics: File systems 2 Physical structure of a harddisk (http://www.storagereview.com/guide2000/hdd/...) Michael Sonntag Computer forensics: File systems 3 General aspects of harddisks z Several different sized exist Æ Typically named according to the size of the disks, not the case » Note that these are not absolutely accurate (3,5" drive Æ 3,74" disk)! z Rotating disks = „platters“ Æ Made from aluminium or compounds; perhaps even glass Æ Coating: Ironoxide (=rust), Cobalt, … z "Comb" with read-/write heads z Landing Zone / Auto Parking: Resting the head on the surface when not spinning in an area where there is no data Æ In olden times: Manual. Today fully automatic z Impenetrable to dust, but not airtight z „Geometry“ Æ Number of platters, heads, cylinders, sectors z Reserve tracks to enable size guarantee (every disk has phys. errors!) z SMART = Self-Monitoring Analysis and Reporting Technology Michael Sonntag Computer forensics: File systems 4 Tracks and sectors z Formatting the disk creates a file A sector system on the media Æ Which must be able to address individual "parts"! z A disk is divided into (thousands) of concentric circles = tracks A track z Each track is subdivided into sectors of each 512 bytes Æ Not every track has the same number of sectors, however! Track 0 = At the outside z sector = The smallest addressable unit on a disk (="parts") Æ Because of various reasons, larger One disk (upper surface!) units might be created on higher levels » Example: Clusters, partitions, directories, files, … Michael Sonntag Computer forensics: File systems 5 Tracks and sectors z 5,25" disk Æ 2 sides Æ á 40 tracks Æ á 9 sectors z Space for data: Æ 2*40*9*512 Æ 368640 Bytes » =360 kBytes Image: 20 tracks, 16 sectors Source: http://www.storagereview.com/guide2000/ref/hdd/geom/tracks.html Michael Sonntag Computer forensics: File systems 6 ZBR Zoned Bit Recording z Zones with different number of sectors per track Æ Why not different for each track? Æ Because, … 15 0 14 1 11 0 ... ... 1 2 7 0 ... 1 2 3 ... ... 4 ... Source: http://www.storagereview.com/guide2000/hdd/... Michael Sonntag Computer forensics: File systems 7 Cylinders z All tracks on a harddisk which are aligned Æ A harddisk may consist of several physical disks (=platters) Æ All physical disks spin at the same rate and synchronously (=common shaft) z Accessing data on the same cylinder is possible without moving the heads! Æ All heads are mounted on a single actuator arm Æ Simultaneous moves z Example: A cylinder of a harddisk with 4 platters consists of 8 tracks Michael Sonntag Computer forensics: File systems 8 Physical structure of platters Sector Track Cylinder 15 0 14 1 0 1 ... 2 2 2 3 1 4 0 ... sec_per_track nr_cyl tracks_per_cyl (16) (3) = Number of heads (3) sec cyl head [0 .. sec_per_track-1] [0 .. nr_cyl-1] [0 .. tracks_per_cyl-1] Michael Sonntag Computer forensics: File systems 9 Introducing "clusters" z Several sectors are combined to a single cluster z Cluster = Smallest part which can be addresses individually by the operating system z Introduced to manage large/variable-size harddisks by OS Æ Example: FAT16 can only address 216 units » 1 unit = 1 sector Æ 32 MB » 1 unit = 1 cluster (=4 sectors each) Æ 128 MB z What about fragmentation? Æ Internal fragmentation: Space between end of file and end of cluster » Increases: File slack Æ Forensic!!! Æ External fragmentation: Clusters are not allocated in "sequence" » Reduced slightly, as less "units" are needed for a single file z Advantages and problems of cluster size? Æ A 1 byte file requires at least a full cluster » Depends strongly on the number of small files! Æ Larger disks are possible Michael Sonntag Computer forensics: File systems 10 Disk-Partition and OS-BOOT z BIOS Æ „Basic Input / Output System“ Æ Provides also information on disks Æ Cannot be changed by a program » Modern computers: Flash-programmable, but often requires setting a jumper on the motherboard to enable this! z MBR Æ Master Boot Record Æ Contains partition information on the disk and a small piece of code (initial loader for the operating system) » This piece of code is executed first Æ Boot sector viruses! Æ Contains the partition table » List of partitions; which is active, set as boot, … Æ Located at Cylinder 0, head 0, sector 1 (harddisks, floppy disks) Michael Sonntag Computer forensics: File systems 11 OS BOOT (1) Hardware Reset CPU starts executing the program at a pre-defined (hard-coded) address BIOS Basic hardware initialisation Selftest (POST) Decision from where the system will boot Floppy A: Harddisk C: CD-ROM D: Michael Sonntag Computer forensics: File systems 12 OS BOOT (2) BIOS Load Master-Boot-Record and execute it Changes on disk may occur! MBR Select the active partition Read Partition-Boot-Record and execute it PBR Execute OS-Loader Changes on disk will occur! OS Start basic filesystem Michael Sonntag Computer forensics: File systems 13 OS BOOT (3) z Boot sequence BIOS M P O Active B Partition B Partition S partition R R Michael Sonntag Computer forensics: File systems 14 The FAT file system z Very old: Was developed by Microsoft for MS-DOS Æ Partially patented! Æ Little overhead Æ Used today still for memory sticks, flash drives, etc. » Not used anymore for "main" OS partitions (NTFS, etx, …) z Big advantage: Standardized Æ This means, available fully on various OS! » NTFS can be used on Linux, but not completely » Ext can be used on Windows, but not completely z Various versions exist: FAT12, FAT16, FAT32 Æ FAT16: Typically used on most flash disks etc.! Æ We will only discuss FAT16 here! z Bad sectors are marked as such only within the cluster z Simple and fast for smaller disks! Michael Sonntag Computer forensics: File systems 15 Properties of FAT16 z Stores only short filenames: 8.3 Æ Long filenames possible through a (patented) extension z Stores creation, modification and access date z Attributes: Read-only, hidden, system, archive z Maximum number of files: 65517 Æ FAT 12 Æ 212, FAT 16 Æ 216, FAT32 Æ 228 Æ Root directory: Typically 512 files; maximum 32767 files » Fixed maximum size; created during formatting z Maximum file size: 2 GB z Maximum volume size: 2 GB (theoretical: 4 GB) z Allows hierarchical directories Æ Each counts against the limit as a file Michael Sonntag Computer forensics: File systems 16 Physical layout of FAT16 Root BS FAT1 FAT2 Data area directory Optional: Reserved sectors z Boot sector: A single sector containing the boot code and the partition table Æ More reserved sectors immediately afterwards possible z FAT1: The File Allocation Table Æ Contains the map to the data area (which clusters used) z FAT2: Copy of FAT1 z Root directory (fixed location!) Æ Location and properties of files » Note: Subdirectories are located in the data area! z Data area: Where files and subdirectories are located Michael Sonntag Computer forensics: File systems 17 The File Allocation Table (FAT16) z Basic concept of storing/accessing a file: 1. Locate file description in root directory 2. Extract from description number of first cluster 3. Read cluster 4. Lookup this cluster number in FAT 5. According to value found, go to step 3 (next cluster) or terminate (last cluster) » Note: FAT-lookup can also be done in a single step for a whole file and cached until all data sectors were read! z Each cluster is described by a number as Æ Unused Æ Used by a file Æ Last cluster in a file Æ Bad cluster Michael Sonntag Computer forensics: File systems 18 The File Allocation Table (FAT16) Index in FAT 0x01 0x20 0x21 0x22 0x23 0x24 0x25 0x26 0x27 0x28 0x29 MBR … 0x0000 0x0022 0x0025 0x0026 0xFFFF 0x0027 0xFFFF 0xFFFF 0xFFF7 0x0000 Cluster number Cluster 0x27 z The example contains 3 files CA FE 00 0D D5 56 A7 … Sector 0x98 z Directory entries: Æ A: Start cluster 0x21 D1 AF 2E 56 51 7A 72 02 A1 … Sector 0x99 Æ B: Start cluster 0x23 CC 08 7A 69 C4 E2 96 … Æ C: Start cluster 0x24 Sector 0x9A End of file z Cluster 0x28 is erroneous FF 00 07 FE 47 11 08 15 FF FF … z Cluster 0x20 and 0x29 are free Sector 0x9B Michael Sonntag Computer forensics: File systems 19 Storing a directory in FAT16 z Like normal file, but format identical to root directory Æ 11 bytes: Name (8.3) Æ 1 byte: Attributes Æ 5 bytes: Creation time and date (10 ms) Æ 2 bytes: Last access date (1 day, no time!) Æ 4 bytes: Last modification time and date (2 s) Æ 2 bytes: First cluster number Æ 4 bytes: File size in bytes Æ 3 bytes: Reserved z Deleting files: Æ Marked as deleted within the directory ONLY Æ Marking is done by setting first filename byte to "E5h" » The FAT is unaffected and can be used to reconstruct the content as long as the sectors are not reused! » The rest of the directory entry remains until reused! Michael Sonntag Computer forensics: File systems 20 FAT 16 and computer forensic z Typically, files are not actually deleted (see above) Æ Unless the physical area is reused, it is recoverable Æ Fragments of FAT chains may exist even then » Partial recovery of files might be possible z There is no "partition" slack within FAT Æ All clusters are used; there are no partitions
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.
  • Allgemeines Abkürzungsverzeichnis

    Allgemeines Abkürzungsverzeichnis

    Allgemeines Abkürzungsverzeichnis L.
  • Study of File System Evolution

    Study of File System Evolution

    Study of File System Evolution Swaminathan Sundararaman, Sriram Subramanian Department of Computer Science University of Wisconsin {swami, srirams} @cs.wisc.edu Abstract File systems have traditionally been a major area of file systems are typically developed and maintained by research and development. This is evident from the several programmer across the globe. At any point in existence of over 50 file systems of varying popularity time, for a file system, there are three to six active in the current version of the Linux kernel. They developers, ten to fifteen patch contributors but a single represent a complex subsystem of the kernel, with each maintainer. These people communicate through file system employing different strategies for tackling individual file system mailing lists [14, 16, 18] various issues. Although there are many file systems in submitting proposals for new features, enhancements, Linux, there has been no prior work (to the best of our reporting bugs, submitting and reviewing patches for knowledge) on understanding how file systems evolve. known bugs. The problems with the open source We believe that such information would be useful to the development approach is that all communication is file system community allowing developers to learn buried in the mailing list archives and aren’t easily from previous experiences. accessible to others. As a result when new file systems are developed they do not leverage past experience and This paper looks at six file systems (Ext2, Ext3, Ext4, could end up re-inventing the wheel. To make things JFS, ReiserFS, and XFS) from a historical perspective worse, people could typically end up doing the same (between kernel versions 1.0 to 2.6) to get an insight on mistakes as done in other file systems.
  • Active@ UNDELETE Documentation

    Active@ UNDELETE Documentation

    Active @ UNDELETE Users Guide | Contents | 2 Contents Legal Statement.........................................................................................................5 Active@ UNDELETE Overview............................................................................. 6 Getting Started with Active@ UNDELETE.......................................................... 7 Active@ UNDELETE Views And Windows...................................................................................................... 7 Recovery Explorer View.......................................................................................................................... 8 Logical Drive Scan Result View..............................................................................................................9 Physical Device Scan View......................................................................................................................9 Search Results View...............................................................................................................................11 File Organizer view................................................................................................................................ 12 Application Log...................................................................................................................................... 13 Welcome View........................................................................................................................................14 Using
  • Active @ UNDELETE Users Guide | TOC | 2

    Active @ UNDELETE Users Guide | TOC | 2

    Active @ UNDELETE Users Guide | TOC | 2 Contents Legal Statement..................................................................................................4 Active@ UNDELETE Overview............................................................................. 5 Getting Started with Active@ UNDELETE........................................................... 6 Active@ UNDELETE Views And Windows......................................................................................6 Recovery Explorer View.................................................................................................... 7 Logical Drive Scan Result View.......................................................................................... 7 Physical Device Scan View................................................................................................ 8 Search Results View........................................................................................................10 Application Log...............................................................................................................11 Welcome View................................................................................................................11 Using Active@ UNDELETE Overview................................................................. 13 Recover deleted Files and Folders.............................................................................................. 14 Scan a Volume (Logical Drive) for deleted files..................................................................15
  • CS 5600 Computer Systems

    CS 5600 Computer Systems

    CS 5600 Computer Systems Lecture 10: File Systems What are We Doing Today? • Last week we talked extensively about hard drives and SSDs – How they work – Performance characterisEcs • This week is all about managing storage – Disks/SSDs offer a blank slate of empty blocks – How do we store files on these devices, and keep track of them? – How do we maintain high performance? – How do we maintain consistency in the face of random crashes? 2 • ParEEons and MounEng • Basics (FAT) • inodes and Blocks (ext) • Block Groups (ext2) • Journaling (ext3) • Extents and B-Trees (ext4) • Log-based File Systems 3 Building the Root File System • One of the first tasks of an OS during bootup is to build the root file system 1. Locate all bootable media – Internal and external hard disks – SSDs – Floppy disks, CDs, DVDs, USB scks 2. Locate all the parEEons on each media – Read MBR(s), extended parEEon tables, etc. 3. Mount one or more parEEons – Makes the file system(s) available for access 4 The Master Boot Record Address Size Descripon Hex Dec. (Bytes) Includes the starEng 0x000 0 Bootstrap code area 446 LBA and length of 0x1BE 446 ParEEon Entry #1 16 the parEEon 0x1CE 462 ParEEon Entry #2 16 0x1DE 478 ParEEon Entry #3 16 0x1EE 494 ParEEon Entry #4 16 0x1FE 510 Magic Number 2 Total: 512 ParEEon 1 ParEEon 2 ParEEon 3 ParEEon 4 MBR (ext3) (swap) (NTFS) (FAT32) Disk 1 ParEEon 1 MBR (NTFS) 5 Disk 2 Extended ParEEons • In some cases, you may want >4 parEEons • Modern OSes support extended parEEons Logical Logical ParEEon 1 ParEEon 2 Ext.
  • 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.
  • W4118: Linux File Systems

    W4118: Linux File Systems

    W4118: Linux file systems Instructor: Junfeng Yang References: Modern Operating Systems (3rd edition), Operating Systems Concepts (8th edition), previous W4118, and OS at MIT, Stanford, and UWisc File systems in Linux Linux Second Extended File System (Ext2) . What is the EXT2 on-disk layout? . What is the EXT2 directory structure? Linux Third Extended File System (Ext3) . What is the file system consistency problem? . How to solve the consistency problem using journaling? Virtual File System (VFS) . What is VFS? . What are the key data structures of Linux VFS? 1 Ext2 “Standard” Linux File System . Was the most commonly used before ext3 came out Uses FFS like layout . Each FS is composed of identical block groups . Allocation is designed to improve locality inodes contain pointers (32 bits) to blocks . Direct, Indirect, Double Indirect, Triple Indirect . Maximum file size: 4.1TB (4K Blocks) . Maximum file system size: 16TB (4K Blocks) On-disk structures defined in include/linux/ext2_fs.h 2 Ext2 Disk Layout Files in the same directory are stored in the same block group Files in different directories are spread among the block groups Picture from Tanenbaum, Modern Operating Systems 3 e, (c) 2008 Prentice-Hall, Inc. All rights reserved. 0-13-6006639 3 Block Addressing in Ext2 Twelve “direct” blocks Data Data BlockData Inode Block Block BLKSIZE/4 Indirect Data Data Blocks BlockData Block Data (BLKSIZE/4)2 Indirect Block Data BlockData Blocks Block Double Block Indirect Indirect Blocks Data Data Data (BLKSIZE/4)3 BlockData Data Indirect Block BlockData Block Block Triple Double Blocks Block Indirect Indirect Data Indirect Data BlockData Blocks Block Block Picture from Tanenbaum, Modern Operating Systems 3 e, (c) 2008 Prentice-Hall, Inc.
  • MSD FATFS Users Guide

    MSD FATFS Users Guide

    Freescale MSD FATFS Users Guide Document Number: MSDFATFSUG Rev. 0 02/2011 How to Reach Us: Home Page: www.freescale.com E-mail: [email protected] USA/Europe or Locations Not Listed: Freescale Semiconductor Technical Information Center, CH370 1300 N. Alma School Road Chandler, Arizona 85224 +1-800-521-6274 or +1-480-768-2130 [email protected] Europe, Middle East, and Africa: Information in this document is provided solely to enable system and Freescale Halbleiter Deutschland GmbH software implementers to use Freescale Semiconductor products. There are Technical Information Center no express or implied copyright licenses granted hereunder to design or Schatzbogen 7 fabricate any integrated circuits or integrated circuits based on the 81829 Muenchen, Germany information in this document. +44 1296 380 456 (English) +46 8 52200080 (English) Freescale Semiconductor reserves the right to make changes without further +49 89 92103 559 (German) notice to any products herein. Freescale Semiconductor makes no warranty, +33 1 69 35 48 48 (French) representation or guarantee regarding the suitability of its products for any particular purpose, nor does Freescale Semiconductor assume any liability [email protected] arising out of the application or use of any product or circuit, and specifically disclaims any and all liability, including without limitation consequential or Japan: incidental damages. “Typical” parameters that may be provided in Freescale Freescale Semiconductor Japan Ltd. Semiconductor data sheets and/or specifications can and do vary in different Headquarters applications and actual performance may vary over time. All operating ARCO Tower 15F parameters, including “Typicals”, must be validated for each customer 1-8-1, Shimo-Meguro, Meguro-ku, application by customer’s technical experts.
  • Improving Journaling File System Performance in Virtualization

    Improving Journaling File System Performance in Virtualization

    SOFTWARE – PRACTICE AND EXPERIENCE Softw. Pract. Exper. 2012; 42:303–330 Published online 30 March 2011 in Wiley Online Library (wileyonlinelibrary.com). DOI: 10.1002/spe.1069 VM aware journaling: improving journaling file system performance in virtualization environments Ting-Chang Huang1 and Da-Wei Chang2,∗,† 1Department of Computer Science, National Chiao Tung University, No. 1001, University Road, Hsinchu 300, Taiwan 2Department of Computer Science and Information Engineering, National Cheng Kung University, No. 1, Ta-Hsueh Road, Tainan 701, Taiwan SUMMARY Journaling file systems, which are widely used in modern operating systems, guarantee file system consistency and data integrity by logging file system updates to a journal, which is a reserved space on the storage, before the updates are written to the data storage. Such journal writes increase the write traffic to the storage and thus degrade the file system performance, especially in full data journaling, which logs both metadata and data updates. In this paper, a new journaling approach is proposed to eliminate journal writes in server virtualization environments, which are gaining in popularity in server platforms. Based on reliable hardware subsystems and virtual machine monitor (VMM), the proposed approach eliminates journal writes by retaining journal data (i.e. logged file system updates) in the memory of each virtual machine and ensuring the integrity of these journal data through cooperation between the journaling file systems and the VMM. We implement the proposed approach in Linux ext3 in the Xen virtualization environment. According to the performance results, a performance improvement of up to 50.9% is achieved over the full data journaling approach of ext3 due to journal write elimination.
  • Certifying a File System

    Certifying a File System

    Certifying a file system: Correctness in the presence of crashes Tej Chajed, Haogang Chen, Stephanie Wang, Daniel Ziegler, Adam Chlipala, Frans Kaashoek, and Nickolai Zeldovich MIT CSAIL 1 / 28 New file systems (and bugs) are introduced over time Some bugs are serious: security exploits, data loss, etc. File systems are complex and have bugs File systems are complex (e.g., Linux ext4 is ∼60,000 lines of code) and have many bugs: 500 ext3 400 300 200 100 # patches for bugs 0 Jan'04 Jan'05 Jan'06 Jan'07 Jan'08 Jan'09 Jan'10 Jan'11 Cumulative number of patches for file-system bugs in Linux; data from [Lu et al., FAST’13] 2 / 28 Some bugs are serious: security exploits, data loss, etc. File systems are complex and have bugs File systems are complex (e.g., Linux ext4 is ∼60,000 lines of code) and have many bugs: 500 ext3 400 ext4 xfs 300 reiserfs 200 jfs btrfs 100 # patches for bugs 0 Jan'04 Jan'05 Jan'06 Jan'07 Jan'08 Jan'09 Jan'10 Jan'11 Cumulative number of patches for file-system bugs in Linux; data from [Lu et al., FAST’13] New file systems (and bugs) are introduced over time 2 / 28 File systems are complex and have bugs File systems are complex (e.g., Linux ext4 is ∼60,000 lines of code) and have many bugs: 500 ext3 400 ext4 xfs 300 reiserfs 200 jfs btrfs 100 # patches for bugs 0 Jan'04 Jan'05 Jan'06 Jan'07 Jan'08 Jan'09 Jan'10 Jan'11 Cumulative number of patches for file-system bugs in Linux; data from [Lu et al., FAST’13] New file systems (and bugs) are introduced over time Some bugs are serious: security exploits, data loss, etc.
  • XFS: There and Back ...And There Again? Slide 1 of 38

    XFS: There and Back ...And There Again? Slide 1 of 38

    XFS: There and Back.... .... and There Again? Dave Chinner <[email protected]> <[email protected]> XFS: There and Back .... and There Again? Slide 1 of 38 Overview • Story Time • Serious Things • These Days • Shiny Things • Interesting Times XFS: There and Back .... and There Again? Slide 2 of 38 Story Time • Way back in the early '90s • Storage exceeding 32 bit capacities • 64 bit CPUs, large scale MP • Hundreds of disks in a single machine • XFS: There..... Slide 3 of 38 "x" is for Undefined xFS had to support: • Fast Crash Recovery • Large File Systems • Large, Sparse Files • Large, Contiguous Files • Large Directories • Large Numbers of Files • - Scalability in the XFS File System, 1995 http://oss.sgi.com/projects/xfs/papers/xfs_usenix/index.html XFS: There..... Slide 4 of 38 The Early Years XFS: There..... Slide 5 of 38 The Early Years • Late 1994: First Release, Irix 5.3 • Mid 1996: Default FS, Irix 6.2 • Already at Version 4 • Attributes • Journalled Quotas • link counts > 64k • feature masks • • XFS: There..... Slide 6 of 38 The Early Years • • Allocation alignment to storage geometry (1997) • Unwritten extents (1998) • Version 2 directories (1999) • mkfs time configurable block size • Scalability to tens of millions of directory entries • • XFS: There..... Slide 7 of 38 What's that Linux Thing? • Feature development mostly stalled • Irix development focussed on CXFS • New team formed for Linux XFS port! • Encumberance review! • Linux was missing lots of bits XFS needed • Lot of work needed • • XFS: There and..... Slide 8 of 38 That Linux Thing? XFS: There and..... Slide 9 of 38 Light that fire! • 2000: SGI releases XFS under GPL • • 2001: First stable XFS release • • 2002: XFS merged into 2.5.36 • • JFS follows similar timeline • XFS: There and....