Fast Storage for File System Metadata

Total Page:16

File Type:pdf, Size:1020Kb

Fast Storage for File System Metadata Fast Storage for File System Metadata Kai Ren CMU-CS-17-121 2017/09/26 School of Computer Science Carnegie Mellon University Pittsburgh, PA 15213 Thesis Committee: Garth A. Gibson, Chair Dave G. Andersen Greg R. Ganger Brent B Welch (Google) Submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy. Copyright © 2017 Kai Ren This research was sponsored by the Moore Foundation under grant number 2160, Los Alamos National Security, LLC under grant numbers 161465-1 and 288103, and the ISTC-CC. The views and conclusions contained in this document are those of the author and should not be interpreted as representing the official policies, either expressed or implied, of any sponsoring institution, the U.S. government or any other entity. Keywords: File System, Metadata Management, Log-Structured Approach, Caching Dedicated to my family. iv Abstract In an era of big data, the rapid growth of data that many companies and organizations produce and manage continues to drive efforts to im- prove the scalability of storage systems. The number of objects presented in storage systems continue to grow, making metadata management crit- ical to the overall performance of file systems. Many modern parallel applications are shifting toward shorter durations and larger degrees of parallelism. Such trends continue to make storage systems to experience more diverse metadata intensive workloads. The goal of this dissertation is to improve metadata management in both local and distributed file systems. The dissertation focuses on two aspects. One is to improve the out-of-core representation of file system metadata, by exploring the use of log-structured multi-level approaches to provide a unified and efficient representation for different types of secondary storage devices (e.g., traditional hard disk and solid state disk). The other aspect is to demonstrate that such representation also can be flexibly integrated with many namespace distribution mechanisms to scale metadata performance of distributed file systems, and provide better support for a variety of big data applications in data center environment. vi Acknowledgments First and foremost, I am greatly indebted to my advisor, Garth Gib- son for his guidance and support of my PhD research. I would also like to thank my thesis committee members Dave Andersen, Greg Ganger, and Brent Welch for their insightful feedback and comments. I would also like to express my gratitude towards my collaborators, collegues, and friends with whom I spent amazing six years: Yoshihisa Abe, Magdalena Balazinska, Vishnu Naresh Boddeti, Zhuo Chen, Christos Faloutsos, Bin Fan, Bin Fu, Gary Grider, Fan Guo, Bill Howe, Wenlu Hu, Junchen Jiang, Jin Kyu Kim, Yunchuan Kong, YongChul Kwon, Ni Lao, Lei Li, Boyan Li, Hyeontaek Lim, Liu Liu, Xi Liu, Yanjin Long, Julio Lopez, Iulian Moraru, Swapnil Patil, Andew Pavlo, Richard Peng, Amar Phanishayee, Milo Polte, Long Qin, Raja R. Sambasivan, Ilari Shafer, Julian Shun, Jiri Simsa, Pingzhong Tang, Wittawat Tantisiriroj, Yuandong Tian, Yuan- dong Tian, Vijay Vasudevan, Jingliang Wei, Guang Xiang, Lin Xiao, Lianghong Xu, Zi Yang, Junming Yin, Yin Zhang, Xin Zhang, Le Zhao, Qing Zheng, Dong Zhou, Zongwei Zhou. Finally, this thesis would not be possible without the support from my parents Yanjun Ren and Weinian Zhang, as well as my wife, Jieqiong Liu. viii Contents Contents ix List of Figures xiii List of Tables xix 1 Introduction1 1.1 Thesis Statement.............................2 1.2 Results Overview.............................3 1.2.1 Out-of-core Metadata Representation..............3 1.2.2 In-memory Index Optimization.................4 1.2.3 Distributed Metadata Management...............4 1.3 Thesis Contribution............................5 2 Background and Related Work7 2.1 Overview of File System Architecture..................7 2.2 In-Memory and External Memory Index................8 2.2.1 In-Memory Indexes........................9 2.2.2 External Memory Indexes.................... 10 2.3 Metadata Management for Local File Systems............. 11 2.3.1 Optimizations for Traditional Disk Model........... 11 2.3.2 Optimizations for Solid State Disks............... 13 ix 2.4 Metadata Management for Distributed Systems............ 13 2.4.1 Namespace Distribution..................... 13 2.4.2 Metadata Caching........................ 14 2.4.3 Large Directories Support.................... 14 2.4.4 Bulk Loading Optimization................... 15 2.5 Storage Systems without File System APIs............... 15 3 Metadata Workload Analysis 19 3.1 Data Sets Overview............................ 20 3.2 File System Namespace Statistics.................... 21 3.3 Dynamic Behaviors in Metadata Workload............... 23 3.4 Statistical Properties of Metadata Operations............. 26 3.5 Lessons from Workload Analysis..................... 29 4 TableFS: A Stacked File System Design Layering on Key-Value Store 31 4.1 Background................................ 32 4.1.1 Analysis of File System Metadata Operations......... 32 4.1.2 LSM-Tree and Its Implementation LevelDB.......... 33 4.2 Design Overview of TableFS....................... 36 4.2.1 Local File System as Object Store................ 36 4.2.2 Table Schema........................... 37 4.2.3 Hard Links............................ 38 4.2.4 Scan Operation Optimization.................. 39 4.2.5 Inode Number Allocation.................... 39 4.2.6 Concurrency Control....................... 39 4.2.7 Journaling............................. 40 4.2.8 Column-Style Table for Faster Insertion............. 40 4.2.9 TableFS in the Kernel...................... 41 x 4.3 Evaluation................................. 43 4.3.1 Evaluation System........................ 43 4.3.2 Data-Intensive Macrobenchmark................. 43 4.3.3 TableFS-FUSE Overhead Analysis............... 46 4.3.4 Metadata-Intensive Microbenchmark.............. 49 4.3.5 Column-Style Metadata Storage Schema............ 55 4.4 Summary................................. 57 5 SlimFS: Space Efficient Indexing and Balanced Read-Write Perfor- mance 59 5.1 The Analysis of Log-Structured Designs................ 61 5.1.1 I/O Cost Analysis of Log-Structured Merge Tree........ 61 5.1.2 Stepped-Merge Algorithm: Reducing Write Amplification in Compaction............................ 62 5.1.3 Optimizing In-memory Indexes and Filters........... 63 5.2 The Design Overview of SlimFS..................... 65 5.2.1 The SlimFS Architecture..................... 65 5.2.2 SlimDB’s Compact Index and Multi-Store Design....... 66 5.3 Design of Compact Index and Filter in SlimDB............ 67 5.3.1 Three-Level Index: Compact Block Index for SSTable..... 67 5.3.2 Multi-Level Cuckoo Filter: Improve Tail Latency....... 72 5.3.3 Implementation of SlimDB.................... 77 5.4 Analytic Model for Selecting Indexes and Filters............ 77 5.5 Evaulation................................. 80 5.5.1 Evaluation System........................ 80 5.5.2 Full System Benchmark..................... 81 5.5.3 Compact SSTable Index Microbechmark............ 85 5.5.4 Multi-Level Cuckoo Filters Microbenchmark.......... 87 5.6 Summary................................. 89 xi 6 IndexFS: Metadata Management For Distributed File Systems 91 6.1 IndexFS System Design......................... 92 6.1.1 Dynamic Namespace Partitioning................ 93 6.1.2 Stateless Directory Caching................... 95 6.1.3 Integration with Log-Structured Metadata Storage...... 97 6.1.4 Metadata Bulk Insertion..................... 99 6.1.5 Rename Operation........................ 100 6.1.6 Fault Tolerance.......................... 102 6.2 Comparison of System Designs...................... 103 6.2.1 Table partitioned namespace (Giraffa)............. 104 6.2.2 Replicated directories with sharded files (ShardFS)...... 106 6.2.3 Comparison Summary...................... 109 6.3 Experimental Evaluation......................... 112 6.3.1 Large Directory Scaling..................... 114 6.3.2 Metadata Client Caching..................... 116 6.3.3 Load Balancing.......................... 119 6.3.4 Bulk Insertion and Factor Analysis............... 123 6.3.5 Portability to Multiple File Systems............... 124 6.4 Summary of IndexFS Benefits...................... 126 7 Conclusion and Future Work 129 7.1 Future Work................................ 130 Bibliography 131 xii List of Figures 2.1 Distributed file system architecture. .......................................8 3.1 The distribution of 50th, 90th, and 100th percentile, and maximum directory sizes and file sizes of collected file system samples...... 21 3.2 This scatter plot demonstrates the relation between the size of each file system sample and its maximum directory size. The black line is the trend lines that predicts the relation using linear regression.... 22 3.3 The distribution of directory depth of collected file systems traces. Many file systems have 50% of their directories with a depth lower than 9................................... 23 3.4 This scatter plot demonstrates the relationship between the size of each file system sample and the average depth of objects inside the system. The average depth of the tree increases sub-linearly as the file system size grows........................... 24 3.5 Distribution of file system operations in LinkedIn, Yahoo! and Open- Cloud traces. Most of these workloads are read-intensive, but compli- cated operations like rename also have a significant presence..... 25 3.6 The distribution of each type of metadata operation in a one-day LinkedIn trace over
Recommended publications
  • STAT 625: Statistical Case Studies 1 Our Computing Environment(S)
    John W. Emerson, Department of Statistics, Yale University © 2013 1 STAT 625: Statistical Case Studies John W. Emerson Yale University Abstract This term, I’ll generally present brief class notes and scripts, but much of the lecture material will simply be presented in class and/or available online. However, student participation is a large part of this course, and at any time I may call upon any of you to share some of your work. Be prepared. This won’t be a class where you sit and absorb material. I strongly encourage you to work with other students; you can learn a lot from each other. To get anything out of this course you’ll need to put in the time for the sake of learning and strengthening your skills, not for the sake of jumping through the proverbial hoop. Lesson 1: Learning how to communicate. This document was created using LATEX and Sweave (which is really an R package). There are some huge advantages to a workflow like this, relating to a topic called reproducible research. Here’s my thought: pay your dues now, reap the benefits later. Don’t trust me on everything, but trust me on this. A sister document was created using R Markdown and the markdown package, and this is also acceptable. Microsoft Office is not. So, in today’s class I’ll show you how I produced these documents and I’ll give you the required files. I recommend you figure out how to use LATEX on your own computer. You already have Sweave, because it comes with R.
    [Show full text]
  • The Google File System (GFS)
    The Google File System (GFS), as described by Ghemwat, Gobioff, and Leung in 2003, provided the architecture for scalable, fault-tolerant data management within the context of Google. These architectural choices, however, resulted in sub-optimal performance in regard to data trustworthiness (security) and simplicity. Additionally, the application- specific nature of GFS limits the general scalability of the system outside of the specific design considerations within the context of Google. SYSTEM DESIGN: The authors enumerate their specific considerations as: (1) commodity components with high expectation of failure, (2) a system optimized to handle relatively large files, particularly multi-GB files, (3) most writes to the system are concurrent append operations, rather than internally modifying the extant files, and (4) a high rate of sustained bandwidth (Section 1, 2.1). Utilizing these considerations, this paper analyzes the success of GFS’s design in achieving a fault-tolerant, scalable system while also considering the faults of the system with regards to data-trustworthiness and simplicity. Data-trustworthiness: In designing the GFS system, the authors made the conscious decision not prioritize data trustworthiness by allowing applications to access ‘stale’, or not up-to-date, data. In particular, although the system does inform applications of the chunk-server version number, the designers of GFS encouraged user applications to cache chunkserver information, allowing stale data accesses (Section 2.7.2, 4.5). Although possibly troubling
    [Show full text]
  • A Review on GOOGLE File System
    International Journal of Computer Science Trends and Technology (IJCST) – Volume 4 Issue 4, Jul - Aug 2016 RESEARCH ARTICLE OPEN ACCESS A Review on Google File System Richa Pandey [1], S.P Sah [2] Department of Computer Science Graphic Era Hill University Uttarakhand – India ABSTRACT Google is an American multinational technology company specializing in Internet-related services and products. A Google file system help in managing the large amount of data which is spread in various databases. A good Google file system is that which have the capability to handle the fault, the replication of data, make the data efficient, memory storage. The large data which is big data must be in the form that it can be managed easily. Many applications like Gmail, Facebook etc. have the file systems which organize the data in relevant format. In conclusion the paper introduces new approaches in distributed file system like spreading file’s data across storage, single master and appends writes etc. Keywords:- GFS, NFS, AFS, HDFS I. INTRODUCTION III. KEY IDEAS The Google file system is designed in such a way that 3.1. Design and Architecture: GFS cluster consist the data which is spread in database must be saved in of single master and multiple chunk servers used by a arrange manner. multiple clients. Since files to be stored in GFS are The arrangement of data is in the way that it can large, processing and transferring such huge files can reduce the overhead load on the server, the consume a lot of bandwidth. To efficiently utilize availability must be increased, throughput should be bandwidth files are divided into large 64 MB size highly aggregated and much more services to make chunks which are identified by unique 64-bit chunk the available data more accurate and reliable.
    [Show full text]
  • System Calls and I/O
    System Calls and I/O CS 241 January 27, 2012 Copyright ©: University of Illinois CS 241 Staff 1 This lecture Goals Get you familiar with necessary basic system & I/O calls to do programming Things covered in this lecture Basic file system calls I/O calls Signals Note: we will come back later to discuss the above things at the concept level Copyright ©: University of Illinois CS 241 Staff 2 System Calls versus Function Calls? Copyright ©: University of Illinois CS 241 Staff 3 System Calls versus Function Calls Function Call Process fnCall() Caller and callee are in the same Process - Same user - Same “domain of trust” Copyright ©: University of Illinois CS 241 Staff 4 System Calls versus Function Calls Function Call System Call Process Process fnCall() sysCall() OS Caller and callee are in the same Process - Same user - OS is trusted; user is not. - Same “domain of trust” - OS has super-privileges; user does not - Must take measures to prevent abuse Copyright ©: University of Illinois CS 241 Staff 5 System Calls System Calls A request to the operating system to perform some activity System calls are expensive The system needs to perform many things before executing a system call The computer (hardware) saves its state The OS code takes control of the CPU, privileges are updated. The OS examines the call parameters The OS performs the requested function The OS saves its state (and call results) The OS returns control of the CPU to the caller Copyright ©: University of Illinois CS 241 Staff 6 Steps for Making a System Call
    [Show full text]
  • F1 Query: Declarative Querying at Scale
    F1 Query: Declarative Querying at Scale Bart Samwel John Cieslewicz Ben Handy Jason Govig Petros Venetis Chanjun Yang Keith Peters Jeff Shute Daniel Tenedorio Himani Apte Felix Weigel David Wilhite Jiacheng Yang Jun Xu Jiexing Li Zhan Yuan Craig Chasseur Qiang Zeng Ian Rae Anurag Biyani Andrew Harn Yang Xia Andrey Gubichev Amr El-Helw Orri Erling Zhepeng Yan Mohan Yang Yiqun Wei Thanh Do Colin Zheng Goetz Graefe Somayeh Sardashti Ahmed M. Aly Divy Agrawal Ashish Gupta Shiv Venkataraman Google LLC [email protected] ABSTRACT 1. INTRODUCTION F1 Query is a stand-alone, federated query processing platform The data processing and analysis use cases in large organiza- that executes SQL queries against data stored in different file- tions like Google exhibit diverse requirements in data sizes, la- based formats as well as different storage systems at Google (e.g., tency, data sources and sinks, freshness, and the need for custom Bigtable, Spanner, Google Spreadsheets, etc.). F1 Query elimi- business logic. As a result, many data processing systems focus on nates the need to maintain the traditional distinction between dif- a particular slice of this requirements space, for instance on either ferent types of data processing workloads by simultaneously sup- transactional-style queries, medium-sized OLAP queries, or huge porting: (i) OLTP-style point queries that affect only a few records; Extract-Transform-Load (ETL) pipelines. Some systems are highly (ii) low-latency OLAP querying of large amounts of data; and (iii) extensible, while others are not. Some systems function mostly as a large ETL pipelines. F1 Query has also significantly reduced the closed silo, while others can easily pull in data from other sources.
    [Show full text]
  • A Study of Cryptographic File Systems in Userspace
    Turkish Journal of Computer and Mathematics Education Vol.12 No.10 (2021), 4507-4513 Research Article A study of cryptographic file systems in userspace a b c d e f Sahil Naphade , Ajinkya Kulkarni Yash Kulkarni , Yash Patil , Kaushik Lathiya , Sachin Pande a Department of Information Technology PICT, Pune, India [email protected] b Department of Information Technology PICT, Pune, India [email protected] c Department of Information Technology PICT, Pune, India [email protected] d Department of Information Technology PICT, Pune, India [email protected] e Veritas Technologies Pune, India, [email protected] f Department of Information Technology PICT, Pune, India [email protected] Article History: Received: 10 January 2021; Revised: 12 February 2021; Accepted: 27 March 2021; Published online: 28 April 2021 Abstract: With the advancements in technology and digitization, the data storage needs are expanding; along with the data breaches which can expose sensitive data to the world. Thus, the security of the stored data is extremely important. Conventionally, there are two methods of storage of the data, the first being hiding the data and the second being encryption of the data. However, finding out hidden data is simple, and thus, is very unreliable. The second method, which is encryption, allows for accessing the data by only the person who encrypted the data using his passkey, thus allowing for higher security. Typically, a file system is implemented in the kernel of the operating systems. However, with an increase in the complexity of the traditional file systems like ext3 and ext4, the ones that are based in the userspace of the OS are now allowing for additional features on top of them, such as encryption-decryption and compression.
    [Show full text]
  • Lab #6: Stat Overview Stat
    February 17, 2017 CSC 357 1 Lab #6: Stat Overview The purpose of this lab is for you to retrieve from the filesystem information pertaining to specified files. You will use portions of this lab in Assignment #4, so be sure to write code that can be reused. stat Write a simplified version of the stat utility available on some Unix distributions. This program should take any number of file names as command-line arguments and output information pertaining to each file as described below (you should use the stat system call). The output from your program should look as follows: File: ‘Makefile’ Type: Regular File Size: 214 Inode: 4702722 Links: 1 Access: -rw------- The stat system call provides more information about a file, but this lab only requires the above. The format of each field follows: • File: the name of the file being examined. • Type: the type of file output as “Regular File”, “Directory”, “Character Device”, “Block Device”, “FIFO”, or “Symbolic Link” • Size: the number of bytes in the file. • Inode: the file’s inode. • Links: the number of links to the file. • Access: the access permissions for the file. This field is the most involved since the output string can take many forms. The first bit of the access permissions denotes the type (similar to the second field above). The valid characters for the first bit are: b – Block special file. c – Character special file. d – Directory. l – Symbolic link. p – FIFO. - – Regular file. The remaining bits denote the read, write and execute permissions for the user, group, and others.
    [Show full text]
  • Cloud Computing Bible Is a Wide-Ranging and Complete Reference
    A thorough, down-to-earth look Barrie Sosinsky Cloud Computing Barrie Sosinsky is a veteran computer book writer at cloud computing specializing in network systems, databases, design, development, The chance to lower IT costs makes cloud computing a and testing. Among his 35 technical books have been Wiley’s Networking hot topic, and it’s getting hotter all the time. If you want Bible and many others on operating a terra firma take on everything you should know about systems, Web topics, storage, and the cloud, this book is it. Starting with a clear definition of application software. He has written nearly 500 articles for computer what cloud computing is, why it is, and its pros and cons, magazines and Web sites. Cloud Cloud Computing Bible is a wide-ranging and complete reference. You’ll get thoroughly up to speed on cloud platforms, infrastructure, services and applications, security, and much more. Computing • Learn what cloud computing is and what it is not • Assess the value of cloud computing, including licensing models, ROI, and more • Understand abstraction, partitioning, virtualization, capacity planning, and various programming solutions • See how to use Google®, Amazon®, and Microsoft® Web services effectively ® ™ • Explore cloud communication methods — IM, Twitter , Google Buzz , Explore the cloud with Facebook®, and others • Discover how cloud services are changing mobile phones — and vice versa this complete guide Understand all platforms and technologies www.wiley.com/compbooks Shelving Category: Use Google, Amazon, or
    [Show full text]
  • Comparative Analysis of Distributed and Parallel File Systems' Internal Techniques
    Comparative Analysis of Distributed and Parallel File Systems’ Internal Techniques Viacheslav Dubeyko Content 1 TERMINOLOGY AND ABBREVIATIONS ................................................................................ 4 2 INTRODUCTION......................................................................................................................... 5 3 COMPARATIVE ANALYSIS METHODOLOGY ....................................................................... 5 4 FILE SYSTEM FEATURES CLASSIFICATION ........................................................................ 5 4.1 Distributed File Systems ............................................................................................................................ 6 4.1.1 HDFS ..................................................................................................................................................... 6 4.1.2 GFS (Google File System) ....................................................................................................................... 7 4.1.3 InterMezzo ............................................................................................................................................ 9 4.1.4 CodA .................................................................................................................................................... 10 4.1.5 Ceph.................................................................................................................................................... 12 4.1.6 DDFS ..................................................................................................................................................
    [Show full text]
  • Performance and Scalability of a Sensor Data Storage Framework
    View metadata, citation and similar papers at core.ac.uk brought to you by CORE provided by Aaltodoc Publication Archive Aalto University School of Science Degree Programme in Computer Science and Engineering Paul Tötterman Performance and Scalability of a Sensor Data Storage Framework Master’s Thesis Helsinki, March 10, 2015 Supervisor: Associate Professor Keijo Heljanko Advisor: Lasse Rasinen M.Sc. (Tech.) Aalto University School of Science ABSTRACT OF Degree Programme in Computer Science and Engineering MASTER’S THESIS Author: Paul Tötterman Title: Performance and Scalability of a Sensor Data Storage Framework Date: March 10, 2015 Pages: 67 Major: Software Technology Code: T-110 Supervisor: Associate Professor Keijo Heljanko Advisor: Lasse Rasinen M.Sc. (Tech.) Modern artificial intelligence and machine learning applications build on analysis and training using large datasets. New research and development does not always start with existing big datasets, but accumulate data over time. The same storage solution does not necessarily cover the scale during the lifetime of the research, especially if scaling up from using common workgroup storage technologies. The storage infrastructure at ZenRobotics has grown using standard workgroup technologies. The current approach is starting to show its limits, while the storage growth is predicted to continue and accelerate. Successful capacity planning and expansion requires a better understanding of the patterns of the use of storage and its growth. We have examined the current storage architecture and stored data from different perspectives in order to gain a better understanding of the situation. By performing a number of experiments we determine key properties of the employed technologies. The combination of these factors allows us to make informed decisions about future storage solutions.
    [Show full text]
  • Stat System Administration Guide Updated - November 2018 Software Version - 6.2.0 Contents
    Quest® Stat® 6.2.0 System Administration Guide © 2018 Quest Software Inc. ALL RIGHTS RESERVED. This guide contains proprietary information protected by copyright. The software described in this guide is furnished under a software license or nondisclosure agreement. This software may be used or copied only in accordance with the terms of the applicable agreement. No part of this guide may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying and recording for any purpose other than the purchaser’s personal use without the written permission of Quest Software Inc. The information in this document is provided in connection with Quest Software products. No license, express or implied, by estoppel or otherwise, to any intellectual property right is granted by this document or in connection with the sale of Quest Software products. EXCEPT AS SET FORTH IN THE TERMS AND CONDITIONS AS SPECIFIED IN THE LICENSE AGREEMENT FOR THIS PRODUCT, QUEST SOFTWARE ASSUMES NO LIABILITY WHATSOEVER AND DISCLAIMS ANY EXPRESS, IMPLIED OR STATUTORY WARRANTY RELATING TO ITS PRODUCTS INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT. IN NO EVENT SHALL QUEST SOFTWARE BE LIABLE FOR ANY DIRECT, INDIRECT, CONSEQUENTIAL, PUNITIVE, SPECIAL OR INCIDENTAL DAMAGES (INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF PROFITS, BUSINESS INTERRUPTION OR LOSS OF INFORMATION) ARISING OUT OF THE USE OR INABILITY TO USE THIS DOCUMENT, EVEN IF QUEST SOFTWARE HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. Quest Software makes no representations or warranties with respect to the accuracy or completeness of the contents of this document and reserves the right to make changes to specifications and product descriptions at any time without notice.
    [Show full text]
  • Files and Directories Struct Stat File Types
    struct stat { dev_t st_dev; ino_t st_ino; mode_t st_mode; nlink_t st_nlink; Struct stat uid_t st_uid; gid_t st_gid; dev_t st_rdev; off_t st_size; /* SysV/sco doesn't have the rest... But Solaris, eabi does. */ #if defined(__svr4__) && !defined(__PPC__) && !defined(__sun__) Files and Directories time_t st_atime; time_t st_mtime; time_t st_ctime; #else time_t st_atime; Marco Gruteser long st_spare1; time_t st_mtime; Advanced Programming for Linux long st_spare2; time_t st_ctime; long st_spare3; long st_blksize; long st_blocks; long st_spare4[2]; #endif 1 }; 2 Why does the operating system File types (mode) need to distinguish these? • Regular file • Directory file • Character special file (device access, e.g. serial port) • Block special file (device access, e.g., disk) •FIFO (pipe) • Socket (network connection) • Symbolic link (pointer to another file) 3 4 Some operations only valid on File Access control list certain files • No lseek on Fifo or socket • Every file (includes directories, device • No write on directory files) has • Open on symlink requires redirection – owner user and owner group – Permissions (-rwxr-x---) •… 5 6 Process User- and Group-IDs File access checks • Real user ID • Automatically invoked on file open • Real group ID –Uses effective uid/gid • Effective user ID used for file • Manual invocation through access function possible • Effective group ID access checks What for? –Uses real uid/gid • Saved set-user-ID • Saved set-group-ID saved by exec 7 8 File access checks Setuid / setgid • Requires x permission on all
    [Show full text]