DOCSLIB.ORG

Doctoral Thesis

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Doctoral Thesis Charles University in Prague Faculty of Mathematics and Physics DOCTORAL THESIS Mikul´aˇsPatoˇcka Design and Implementation of the Spad Filesystem Department of Software Engineering Advisor: RNDr. Filip Zavoral, Ph.D. Abstract Title: Design and Implementation of the Spad Filesystem Author: Mgr. Mikul´aˇsPatoˇcka email: [email protected]ff.cuni.cz Department: Department of Software Engineering Faculty of Mathematics and Physics Charles University in Prague, Czech Republic Advisor: RNDr. Filip Zavoral, Ph.D. email: Filip.Zavoral@mff.cuni.cz Mailing address (author): Mikul´aˇsPatoˇcka Voskovcova 37 152 00 Prague, Czech Republic Mailing address (advisor): Dept. of Software Engineering Charles University in Prague Malostransk´en´am. 25 118 00 Prague, Czech Republic WWW: http://artax.karlin.mff.cuni.cz/~mikulas/spadfs/ Abstract: This thesis describes design and implementation of the Spad filesystem. I present my novel method for maintaining filesystem consistency — crash counts. I describe architecture of other filesystems and present my own de- sign decisions in directory management, file allocation information, free space management, block allocation strategy and filesystem checking algorithm. I experimentally evaluate performance of the filesystem. I evaluate performance of the same filesystem on two different operating systems, enabling the reader to make a conclusion on how much the performance of various tasks is affected by operating system and how much by physical layout of data on disk. Keywords: filesystem, operating system, crash counts, extendible hashing, SpadFS Acknowledgments I would like to thank my advisor Filip Zavoral for supporting my work and for reading and making comments on this thesis. I would also like to thank to colleague Leo Galamboˇsfor testing my filesystem on his search engine with 1TB RAID array, which led to fixing some bugs and improving performance. The work was partly supported by the project 1ET100300419 of the Program Infor- mation Society of the Thematic Program II of the National Research Program of the Czech Republic. Content 1. Introduction ..............................................................................................................11 1.1 The structure of this thesis......................................................................................11 1.2 General filesystem architecture ................................................................................12 1.2.1 File allocation subsystem ......................................................................................14 1.2.2 Directory organization subsystem .........................................................................14 1.2.3 Free space management.........................................................................................14 1.2.4 Block allocation strategy.......................................................................................14 1.2.5 Crash recovery subsystem .....................................................................................15 1.2.6 Transparent compression.......................................................................................15 1.2.7 Security information..............................................................................................15 1.2.8 Transparent encryption.........................................................................................16 1.3 Related work............................................................................................................16 1.3.1 The FAT................................................................................................................16 1.3.2 The HPFS .............................................................................................................17 1.3.3 The NTFS.............................................................................................................17 1.3.4 The FFS................................................................................................................18 1.3.5 Ext2 ......................................................................................................................18 1.3.6 Ext3 ......................................................................................................................19 1.3.7 Ext4 ......................................................................................................................19 1.3.8 ReiserFS................................................................................................................19 1.3.9 Reiser4 ..................................................................................................................20 1.3.10 The JFS...............................................................................................................20 1.3.11 The XFS..............................................................................................................21 1.3.12 The ZFS ..............................................................................................................21 1.3.13 The GFS..............................................................................................................21 2. Design goals of the Spad filesystem...........................................................................23 2.1 Extensibility to arbitrarily fast devices....................................................................23 2.2 Good efficiency for both small and large files ..........................................................24 2.3 Reduced code complexity.........................................................................................24 2.4 Fast recovery after crash..........................................................................................25 2.5 Data layout suitable for prefetching.........................................................................25 3. Crash count method..................................................................................................27 3.1 Related work............................................................................................................27 3.1.1 Journaling .............................................................................................................27 3.1.2 Log-structured filesystems.....................................................................................28 3.1.3 Phase tree .............................................................................................................28 3.1.4 Soft updates ..........................................................................................................29 3.1.5 Conclusion.............................................................................................................29 3.2 Overview of crash counts .........................................................................................29 3.3 Data structures ........................................................................................................30 3.4 Mounting, unmounting, syncing ..............................................................................31 3.5 Managing directory entries using crash counts ........................................................32 3.6 Managing other disk structures ...............................................................................33 3.7 Managing file allocation info....................................................................................34 3.8 Requirement of atomic disk sector write..................................................................34 3.9 Avoiding blocking of filesystem activity during sync ...............................................35 3.9.1 Writing buffers twice.............................................................................................36 3.9.2 Write barriers........................................................................................................36 3.9.3 Cache in VFS........................................................................................................37 3.10 Summary................................................................................................................37 4. Directories .................................................................................................................39 4.1 Methods in existing filesystems................................................................................39 4.1.1 The HPFS .............................................................................................................39 4.1.2 The JFS ................................................................................................................40 4.1.3 The XFS ...............................................................................................................40 4.1.4 ReiserFS................................................................................................................41 4.1.5 Ext3 ......................................................................................................................41 4.1.6 Extendible hashing: ZFS and GFS .......................................................................42 4.2 Directories in the Spad filesystem............................................................................43 4.2.1 Modification of the algorithm for the Spad filesystem ..........................................43 4.2.2 Description of the algorithm for managing directories in the Spad filesystem......44 4.3 Summary..................................................................................................................46
Load more

Recommended publications
  • 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.
    [Show full text]
  • Linux 与windows 互操作综述
    2012 年 第 21 卷 第 4 期 http://www.c-s-a.org.cn 计 算 机 系 统 应 用 Linux 与 Windows 互操作综述① 王亚军 (中国人民武装警察部队学院，廊坊 065000) 摘 要：针对 Linux 与 Windows 在桌面领域、网络领域和嵌入式领域的互操作问题，做了综合阐述。在桌面领 域,两者可以互运行对方程序、互处理数据文件、互访问文件系统；在网络领域，两者可以采用共同的网络协议 来支持对方系统中的资源与服务在网络环境下的共享操作；在嵌入式领域，两者可以采用虚拟化和代码重构等 技术来支持对方应用软件在本系统中的交叉开发和向本系统的移植等。 关键词：操作系统；互操作性；兼容内核；虚拟化；文件系统；网络协议；嵌入式系统 Overview of the Interoperability of Linux and Windows WANG Ya-Jun (Chinese People’s Armed Police Forces Academy, Langfang 065000, China) Abstract: Aiming at the problems of interoperability between Linux and Windows in desktop domain, network domain and embedded domain, solutions are systematically illustrated in this paper. In desktop domain, the two operating systems can mutually run programs, can mutually deal with data files, and can mutually access file systems. In network domain, the two systems can support the shared operations of resources and services between them under the network environment by adopting the same network protocols. In embedded domain, by adopting the technologies such as virtualization and code refactoring, the two systems can mutually support the cross development of application softwares in local system, mutually support the transplanting of application softwares to local system. Key words: operating system; interoperability; unified kernel; virtualization; file system; network protocol; embedded system 众所周知，Windows 是迄今为止在商业上最成功 境之间架起桥梁，即实现两者的互操作。 的操作系统，而 Linux 则是目前成长最快的操作系统。 在全球范围内，两者在桌面领域、网络领域和嵌入式 1 操作系统互操作技术 领域展开了激烈的竞争。在桌面领域，各种新版本的 操作系统互操作技术是通过约定的接口或协议实 Linux 系统相继推出，在很大程度上改善了用户体验，
    [Show full text]
  • FORM 10−K RED HAT INC − RHT Filed: April 30, 2007 (Period: February 28, 2007)
    FORM 10−K RED HAT INC − RHT Filed: April 30, 2007 (period: February 28, 2007) Annual report which provides a comprehensive overview of the company for the past year Table of Contents PART I Item 1. Business 3 PART I ITEM 1. BUSINESS ITEM 1A. RISK FACTORS ITEM 1B. UNRESOLVED STAFF COMMENTS ITEM 2. PROPERTIES ITEM 3. LEGAL PROCEEDINGS ITEM 4. SUBMISSION OF MATTERS TO A VOTE OF SECURITY HOLDERS PART II ITEM 5. MARKET FOR REGISTRANT S COMMON EQUITY, RELATED STOCKHOLDER MATTERS AND ISSUER PURCHASES OF E ITEM 6. SELECTED FINANCIAL DATA ITEM 7. MANAGEMENT S DISCUSSION AND ANALYSIS OF FINANCIAL CONDITION AND RESULTS OF OPERATIONS ITEM 7A. QUANTITATIVE AND QUALITATIVE DISCLOSURES ABOUT MARKET RISK ITEM 8. FINANCIAL STATEMENTS AND SUPPLEMENTARY DATA ITEM 9. CHANGES IN AND DISAGREEMENTS WITH ACCOUNTANTS ON ACCOUNTING AND FINANCIAL DISCLOSURE ITEM 9A. CONTROLS AND PROCEDURES ITEM 9B. OTHER INFORMATION Part III ITEM 10. DIRECTORS, EXECUTIVE OFFICERS AND CORPORATE GOVERNANCE ITEM 11. EXECUTIVE COMPENSATION ITEM 12. SECURITY OWNERSHIP OF CERTAIN BENEFICIAL OWNERS AND MANAGEMENT AND RELATED STOCKHOLDER MATT ITEM 13. CERTAIN RELATIONSHIPS AND RELATED TRANSACTIONS, AND DIRECTOR INDEPENDENCE ITEM 14. PRINCIPAL ACCOUNTANT FEES AND SERVICES PART IV ITEM 15. EXHIBITS, FINANCIAL STATEMENT SCHEDULES SIGNATURES EX−21.1 (SUBSIDIARIES OF RED HAT) EX−23.1 (CONSENT PF PRICEWATERHOUSECOOPERS LLP) EX−31.1 (CERTIFICATION) EX−31.2 (CERTIFICATION) EX−32.1 (CERTIFICATION) Table of Contents UNITED STATES SECURITIES AND EXCHANGE COMMISSION Washington, D.C. 20549 FORM 10−K Annual Report Pursuant to Sections 13 or 15(d) of the Securities Exchange Act of 1934 (Mark One) x Annual Report Pursuant to Section 13 or 15(d) of the Securities Exchange Act of 1934 For the fiscal year ended February 28, 2007 OR ¨ Transition Report Pursuant to Section 13 or 15(d) of the Securities Exchange Act of 1934 For the transition period from to .
    [Show full text]
  • Filesystem Considerations for Embedded Devices ELC2015 03/25/15
    Filesystem considerations for embedded devices ELC2015 03/25/15 Tristan Lelong Senior embedded software engineer Filesystem considerations ABSTRACT The goal of this presentation is to answer a question asked by several customers: which filesystem should you use within your embedded design’s eMMC/SDCard? These storage devices use a standard block interface, compatible with traditional filesystems, but constraints are not those of desktop PC environments. EXT2/3/4, BTRFS, F2FS are the first of many solutions which come to mind, but how do they all compare? Typical queries include performance, longevity, tools availability, support, and power loss robustness. This presentation will not dive into implementation details but will instead summarize provided answers with the help of various figures and meaningful test results. 2 TABLE OF CONTENTS 1. Introduction 2. Block devices 3. Available filesystems 4. Performances 5. Tools 6. Reliability 7. Conclusion Filesystem considerations ABOUT THE AUTHOR • Tristan Lelong • Embedded software engineer @ Adeneo Embedded • French, living in the Pacific northwest • Embedded software, free software, and Linux kernel enthusiast. 4 Introduction Filesystem considerations Introduction INTRODUCTION More and more embedded designs rely on smart memory chips rather than bare NAND or NOR. This presentation will start by describing: • Some context to help understand the differences between NAND and MMC • Some typical requirements found in embedded devices designs • Potential filesystems to use on MMC devices 6 Filesystem considerations Introduction INTRODUCTION Focus will then move to block filesystems. How they are supported, what feature do they advertise. To help understand how they compare, we will present some benchmarks and comparisons regarding: • Tools • Reliability • Performances 7 Block devices Filesystem considerations Block devices MMC, EMMC, SD CARD Vocabulary: • MMC: MultiMediaCard is a memory card unveiled in 1997 by SanDisk and Siemens based on NAND flash memory.
    [Show full text]
  • Netinfo 2009-06-11 Netinfo 2009-06-11
    Netinfo 2009-06-11 Netinfo 2009-06-11 Microsoft släppte 2009-06-09 tio uppdateringar som täpper till 31 stycken säkerhetshål i bland annat Windows, Internet Explorer, Word, Excel, Windows Search. 18 av buggfixarna är märkta som kritiska och elva av dem är märkta som viktiga, uppdateringarna finns för både servrar och arbetsstationer. Säkerhetsuppdateringarna finns tillgängliga på Windows Update. Den viktigaste säkerhetsuppdateringen av de som släpptes är den för Internet Explorer 8. Netinfo 2009-06-11 Security Updates available for Adobe Reader and Acrobat Release date: June 9, 2009 Affected software versions Adobe Reader 9.1.1 and earlier versions Adobe Acrobat Standard, Pro, and Pro Extended 9.1.1 and earlier versions Severity rating Adobe categorizes this as a critical update and recommends that users apply the update for their product installations. These vulnerabilities would cause the application to crash and could potentially allow an attacker to take control of the affected system. Netinfo 2009-06-11 SystemRescueCd Description: SystemRescueCd is a Linux system on a bootable CD-ROM for repairing your system and recovering your data after a crash. It aims to provide an easy way to carry out admin tasks on your computer, such as creating and editing the partitions of the hard disk. It contains a lot of system tools (parted, partimage, fstools, ...) and basic tools (editors, midnight commander, network tools). It is very easy to use: just boot the CDROM. The kernel supports most of the important file systems (ext2/ext3/ext4, reiserfs, reiser4, btrfs, xfs, jfs, vfat, ntfs, iso9660), as well as network filesystems (samba and nfs).
    [Show full text]
  • Filesystems HOWTO Filesystems HOWTO Table of Contents Filesystems HOWTO
    Filesystems HOWTO Filesystems HOWTO Table of Contents Filesystems HOWTO..........................................................................................................................................1 Martin Hinner < [email protected]>, http://martin.hinner.info............................................................1 1. Introduction..........................................................................................................................................1 2. Volumes...............................................................................................................................................1 3. DOS FAT 12/16/32, VFAT.................................................................................................................2 4. High Performance FileSystem (HPFS)................................................................................................2 5. New Technology FileSystem (NTFS).................................................................................................2 6. Extended filesystems (Ext, Ext2, Ext3)...............................................................................................2 7. Macintosh Hierarchical Filesystem − HFS..........................................................................................3 8. ISO 9660 − CD−ROM filesystem.......................................................................................................3 9. Other filesystems.................................................................................................................................3
    [Show full text]
  • Zack's Kernel News
    KERNEL NEWS ZACK’S KERNEL NEWS ReiserFS Turmoil Their longer term plan, Alexander Multiport Card driver, again naming In light of recent events surrounding says, depends on what happens with himself the maintainer. Hans Reiser (http:// www. linux-maga- Hans. If Hans is released, the developers Jiri’s been submitting a number of zine. com/ issue/ 73/ Linux_World_News. intend to proceed as before. If he is not patches for these drivers, so it makes pdf), the question of how to continue released, Alexander’s best guess is that sense he would maintain them if he ReiserFS development came up on the the developers will try to appoint a wished; in any event, no other kernel linux-kernel mailing list. Alexander proxy to run Namesys. hacker has spoken up to claim the role. Lyamin from Hans’s Namesys company offered his take on the situation. He said Status of sysctl Filesystem Benchmarks that ReiserFS 3 has pretty much stabi- In keeping with Linus Torvalds’ recent Some early tests have indicated that ext4 lized into bugfix mode, though Suse assertions that it is never acceptable to is faster with disk writes than either ext3 folks had been adding new features like break user-space, Albert Cahalan volun- or Reiser4. There was general interest in ACL support. So ReiserFS 3 would go on teered to maintain the sysctl code if it these results, though the tests had some as before. couldn’t be removed. But Linus pointed problems (the tester thought delayed In terms of Reiser4, however, Alexan- out that really nothing actually used allocation was part of ext4, when that der said that he and the other Reiser de- sysctl (the implication being that it feature has not yet been merged into velopers were still addressing the techni- wouldn’t actually break anything to get Andrew Morton’s tree).
    [Show full text]
  • Smart Home Automation with Linux Smart
    CYAN YELLOW MAGENTA BLACK PANTONE 123 C BOOKS FOR PROFESSIONALS BY PROFESSIONALS® THE EXPERT’S VOICE® IN LINUX Companion eBook Available Smart Home Automation with Linux Smart Dear Reader, With this book you will turn your house into a smart and automated home. You will learn how to put together all the hardware and software needed for Automation Home home automation, to control appliances such as your teakettle, CCTV, light switches, and TV. You’ll be taught about the devices you can build, adapt, or Steven Goodwin, Author of hack yourself from existing technology to accomplish these goals. Cross-Platform Game In Smart Home Automation with Linux, you’ll discover the scope and possi- Programming bilities involved in creating a practical digital lifestyle. In the realm of media and Game Developer’s Open media control, for instance, you’ll learn how you can read TV schedules digitally Source Handbook and use them to program video remotely through e-mail, SMS, or a web page. You’ll also learn the techniques for streaming music and video from one machine to another, how to give your home its own Twitter and e-mail accounts for sending automatic status reports, and the ability to remotely control the home Smart Home lights or heating system. Also, Smart Home Automation with Linux describes how you can use speech synthesis and voice recognition systems as a means to converse with your household devices in new, futuristic, ways. Additionally, I’ll also show you how to implement computer-controlled alarm clocks that can speak your daily calendar, news reports, train delays, and local with weather forecasts.
    [Show full text]
  • State of the Art: Where We Are with the Ext3 Filesystem
    State of the Art: Where we are with the Ext3 filesystem Mingming Cao, Theodore Y. Ts’o, Badari Pulavarty, Suparna Bhattacharya IBM Linux Technology Center {cmm, theotso, pbadari}@us.ibm.com, [email protected] Andreas Dilger, Alex Tomas, Cluster Filesystem Inc. [email protected], [email protected] Abstract 1 Introduction Although the ext2 filesystem[4] was not the first filesystem used by Linux and while other filesystems have attempted to lay claim to be- ing the native Linux filesystem (for example, The ext2 and ext3 filesystems on Linux R are when Frank Xia attempted to rename xiafs to used by a very large number of users. This linuxfs), nevertheless most would consider the is due to its reputation of dependability, ro- ext2/3 filesystem as most deserving of this dis- bustness, backwards and forwards compatibil- tinction. Why is this? Why have so many sys- ity, rather than that of being the state of the tem administrations and users put their trust in art in filesystem technology. Over the last few the ext2/3 filesystem? years, however, there has been a significant amount of development effort towards making There are many possible explanations, includ- ext3 an outstanding filesystem, while retaining ing the fact that the filesystem has a large and these crucial advantages. In this paper, we dis- diverse developer community. However, in cuss those features that have been accepted in our opinion, robustness (even in the face of the mainline Linux 2.6 kernel, including direc- hardware-induced corruption) and backwards tory indexing, block reservation, and online re- compatibility are among the most important sizing.
    [Show full text]
  • Model-Based Failure Analysis of Journaling File Systems
    Model-Based Failure Analysis of Journaling File Systems Vijayan Prabhakaran, Andrea C. Arpaci-Dusseau, and Remzi H. Arpaci-Dusseau University of Wisconsin, Madison Computer Sciences Department 1210, West Dayton Street, Madison, Wisconsin {vijayan, dusseau, remzi}@cs.wisc.edu Abstract To analyze such file systems, we develop a novel model- based fault-injection technique. Specifically, for the file We propose a novel method to measure the dependability system under test, we develop an abstract model of its up- of journaling file systems. In our approach, we build models date behavior, e.g., how it orders writes to disk to maintain of how journaling file systems must behave under different file system consistency. By using such a model, we can journaling modes and use these models to analyze file sys- inject faults at various “interesting” points during a file sys- tem behavior under disk failures. Using our techniques, we tem transaction, and thus monitor how the system reacts to measure the robustness of three important Linux journaling such failures. In this paper, we focus only on write failures file systems: ext3, Reiserfs and IBM JFS. From our anal- because file system writes are those that change the on-disk ysis, we identify several design flaws and correctness bugs state and can potentially lead to corruption if not properly present in these file systems, which can cause serious file handled. system errors ranging from data corruption to unmountable We use this fault-injection methodology to test three file systems. widely used Linux journaling file systems: ext3 [19], Reis- erfs [14] and IBM JFS [1].
    [Show full text]
  • NTFS from Wikipedia, the Free Encyclopedia Jump To: Navigation, Search NTFS Developer Microsoft Introduced July 1993 (Windows
    NTFS From Wikipedia, the free encyclopedia Jump to: navigation, search NTFS Developer Microsoft Introduced July 1993 (Windows NT 3.1) Partition identifier 0x07 (MBR) EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 (GPT) Structures Directory contents B+ tree[1] File allocation Bitmap/Extents Bad blocks $badclus Limits Max file size 264 bytes (16 EiB) minus 1 KiB [2] Max number of files 4,294,967,295 (232-1)[2] Max filename length 255 UTF-16 code units[3] Max volume size 264 ? 1 clusters [2] Allowed characters in filenames In Posix namespace, any UTF-16 code unit (case sensitive) except U+0000 (NUL) and / (slash). In Win32 namespace, any UTF-16 code unit (case insensitive) except U+0000 (NUL) / (slash) \ (backslash) : (colon) * (asterisk) ? (Question mark) " (quote) < (less than) > (greater than) and | (pipe) [3] Features Dates recorded Creation, modification, POSIX change, access Date range 1 January 1601 ʹ 28 May 60056 (File times are 64-bit numbers counting 100- nanosecond intervals (ten million per second) since 1601, which is 58,000+ years) Date resolution 100ns Forks Yes (see Alternate data streams below) Attributes Read-only, hidden, system, archive, not content indexed, off-line, temporary File system permissions ACLs Transparent compression Per-file, LZ77 (Windows NT 3.51 onward) Transparent encryption Per-file, DESX (Windows 2000 onward), Triple DES (Windows XP onward), AES (Windows XP Service Pack 1, Windows Server 2003 onward) Single Instance Storage Yes Supported operating systems Windows NT family (Windows NT 3.1 to Windows NT 4.0, Windows 2000, Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008) NTFS is the standard file system of Windows NT, including its later versions Windows 2000, Windows XP, Windows Server 2003, Windows Server 2008, and Windows Vista.[4] NTFS supersedes the FAT file system as the preferred file system for Microsoft͛s ͞Windows͟-branded operating systems.
    [Show full text]
  • Design and Implementation of the Spad Filesystem
    Charles University in Prague Faculty of Mathematics and Physics DOCTORAL THESIS Mikul´aˇsPatoˇcka Design and Implementation of the Spad Filesystem Department of Software Engineering Advisor: RNDr. Filip Zavoral, Ph.D. Abstract Title: Design and Implementation of the Spad Filesystem Author: Mgr. Mikul´aˇsPatoˇcka email: [email protected]ff.cuni.cz Department: Department of Software Engineering Faculty of Mathematics and Physics Charles University in Prague, Czech Republic Advisor: RNDr. Filip Zavoral, Ph.D. email: Filip.Zavoral@mff.cuni.cz Mailing address (advisor): Dept. of Software Engineering Charles University in Prague Malostransk´en´am. 25 118 00 Prague, Czech Republic WWW: http://artax.karlin.mff.cuni.cz/~mikulas/spadfs/ Abstract: This thesis describes design and implementation of the Spad filesystem. I present my novel method for maintaining filesystem consistency — crash counts. I describe architecture of other filesystems and present my own de- sign decisions in directory management, file allocation information, free space management, block allocation strategy and filesystem checking algorithm. I experimentally evaluate performance of the filesystem. I evaluate performance of the same filesystem on two different operating systems, enabling the reader to make a conclusion on how much the performance of various tasks is affected by operating system and how much by physical layout of data on disk. Keywords: filesystem, operating system, crash counts, extendible hashing, SpadFS Acknowledgments I would like to thank my advisor Filip Zavoral for supporting my work and for reading and making comments on this thesis. I would also like to thank to colleague Leo Galamboˇsfor testing my filesystem on his search engine with 1TB RAID array, which led to fixing some bugs and improving performance.
    [Show full text]