DOCSLIB.ORG

Operating Systems 2020 File Systems

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Operating Systems 2020 1 Operating Systems 2020 File systems November 10, 2020 November 10, 2020 Operating Systems 2020 2 Motivation RAM ... to small to contain all the data ... not persistent beyond the lifetime of a process ... does not easily allow sharing over time... Solution: store stuff on devices (HD, SSD,...) information becomes persistent – no longer dependent on processes, disappears only if deleted administration by operating system November 10, 2020 Operating Systems 2020 3 Main Points File systems Useful abstractions on top of physical devices File system usage patterns File- and Directory Layout November 10, 2020 Operating Systems 2020 4 Users view User does not want to see, know and understand where and how data is stored November 10, 2020 Operating Systems 2020 5 What users want Reliability data survives software crashes etc. data survives device failure Large capacity at low cost High performance Easy Access to data (“finding” data - organisation) Controlled sharing November 10, 2020 Operating Systems 2020 6 Storage Devices Magnetic disks Storage that rarely becomes corrupted Large capacity at low cost Block level random access Slow performance for random access Better performance for streaming access November 10, 2020 Operating Systems 2020 7 Storage Devices Flash memory Storage that rarely becomes corrupted Capacity at intermediate cost (~3 x disk) Block level random access Good performance for reads; worse for random writes November 10, 2020 Operating Systems 2020 8 File System as Illusionist Hides Limitations of Physical Storage Persistence of data stored in file system: Even if crash happens during an update Even if disk block becomes corrupted Even if disk has to be replaced Even if flash memory wears out Naming: Named data instead of disk block numbers Directory organization on top of flat storage Byte addressable data even though devices are block-oriented November 10, 2020 Operating Systems 2020 9 File System as Illusionist (2) Improve performance: Caching data Data placement and data structure organization Security Controlled access to shared data November 10, 2020 Operating Systems 2020 10 types of files regular files text (ASCII or UTF-data) binary data (usually with some internal structure) directories special files (/dev/. , /proc/...) block special files character special files November 10, 2020 Operating Systems 2020 11 accessing data tape drive model sequential access one byte after the other at the end: wind back introduction of floppy disks: any sequence possible random access seek-system-call added allowing to change access-position within file November 10, 2020 Operating Systems 2020 12 File System Workload File sizes Are most files small or large? small Which accounts for more total storage: small or large files? large November 10, 2020 Operating Systems 2020 13 File System Workload File access Are most accesses to small or large files? small Which accounts for more total I/O bytes: small or large files? large November 10, 2020 Operating Systems 2020 14 File System Workload How are files used? Most files are read/written sequentially Some files are read/written randomly Ex: database files, swap files Some files have a pre-defined size at creation Some files start small and grow over time Ex: program stdout, system logs November 10, 2020 Operating Systems 2020 15 Impact on File System Design For small files: Small blocks for storage efficiency Files used together should be stored together For large files: Large blocks for storage efficiciency Contiguous allocation for sequential access Efficient lookup supporting random access November 10, 2020 Operating Systems 2020 16 Impact on File System Design But: we may not know at file creation Whether file will become small or large Whether file is persistent or temporary Whether file will be used sequentially or randomly November 10, 2020 Operating Systems 2020 17 Accessing files - API (Syscalls) Access to files language dependent Implementations build on syscalls creating and deleting files: create(), unlink() reading/writing/positioning from a file: read()/write()/seek() start accessing a file: open() end accessing the file: close() ... November 10, 2020 Operating Systems 2020 18 Design Challenges How do we locate the blocks of a file? Index structure What block size do we use? Index granularity How do we find unused blocks on disk? Free space management November 10, 2020 Operating Systems 2020 19 Design Challenges How can we ensure that blocks are stored “near” each other preserving spatial locality What if machine crashes in middle of a file system op? Reliability November 10, 2020 Operating Systems 2020 20 FS Design Examples FAT FFS NTFS Index structure Linked list Tree (fixed, assym) Tree (dynamic) granularity block block extent free space allocation FAT array Bitmap (fixed location) Bitmap (file) Locality defragmentation Block groups Extents reserve space Best Fit, defragment November 10, 2020 Operating Systems 2020 21 How to find Named Data File Name Directory File Number Index Structure Storage Offset Offset Block Data represented by Filename and Offset (and how many bytes) Directory maps this to FIle number and Offset Index-Structure maps this to Storage and Blocknumber(and likely some offset within that block) November 10, 2020 Operating Systems 2020 22 Directory are files music 320 work 219 foo.txt 871 Directory: File that contains a collection of File Name → file number mappings November 10, 2020 Operating Systems 2020 23 Directories How to find a file in the directory tree Find root directory e.g. stored in a file with a fixed number recursive lookup speed up by caching principle of locality November 10, 2020 Operating Systems 2020 24 Recursive File Name Lookup File 2 bin 737 ˝/˝ usr 924 home 158 File 158 mike 682 ˝/home˝ ada 818 tom 830 File 830 music 320 ˝/home/tom˝ work 219 foo.txt 871 File 871 The quick ˝/home/tom/foo.txt˝ brown fox jumped over the lazy dog. November 10, 2020 Operating Systems 2020 25 Directory API We could use open/read/write/close (from user program) Requires knowing the structure we shall not corrupt directories Operating System must have control over file numbers part of open/create syscall functionality special system calls for directory operations read by user process possible special library functions or syscalls (e.g. getdents - „get directory entries“) helpful November 10, 2020 Operating Systems 2020 26 Directory Layout Directory stored as a file linear search to find filename OK for small directories November 10, 2020 Operating Systems 2020 27 Large Directories: B Trees (XFS) November 10, 2020 Operating Systems 2020 28 Large Directories: Storage November 10, 2020 Operating Systems 2020 29 Linking A file may have multiple names in multiple directories Hard-Link: multiple file directory entries that map different path names to the same file number Soft-Link: map one name to another name (including path) November 10, 2020 Operating Systems 2020 30 Linking - Hard Link November 10, 2020 Operating Systems 2020 31 Linking - Soft Link November 10, 2020 Operating Systems 2020 32 Finding Data We must be able to find the blocks belonging to a file Other goals: support sequential data placement to maximize sequential file access provide efficient random access to any block be efficient for small files be scalable to support large files provide a place to store Metadata November 10, 2020 Operating Systems 2020 33 Case Studies FAT Unix FFS NTFS COW/ZFS November 10, 2020 Operating Systems 2020 34 FAT MS FAT file system implemented late 70ies main file system for MS-DOS and early windows many enhancements FAT-32: 228blocks and 232 − 1bytes Today: Variant still in use for SD-Cards etc. November 10, 2020 Operating Systems 2020 35 FAT-32 November 10, 2020 Operating Systems 2020 36 FAT-32 FAT - File Allocation Table array of 32 bit entries reserved area of volume file: linked list of FAT entries, each entry points to successor or „end of file“ One entry for each block in the volume File number: index of the first entry in the FAT November 10, 2020 Operating Systems 2020 37 FAT free space tracking/locality FAT[i] == 0 → block is free Find free block: search FAT allocation: scan through FAT from last entry allocated may fragment file-system run defragmentation tool November 10, 2020 Operating Systems 2020 38 FAT discussionI simple, widely in use / supported Poor locality → fragmented files Poor random access → need to traverse FAT Limited metadata and access control No hard links limitation of volume and file size max. 228 blocks block size up to 256 KB - internal fragmentation lack of modern reliability techniques November 10, 2020 Operating Systems 2020 39 UNIX FFS Unix Fast File System - released mid 1980 many data-structures identical to Ritchie/Thomposon’s original UNIX FS (1970ies) Tree-based multilevel index locality heuristics Today: ext2/ext3 based on FFS November 10, 2020 Operating Systems 2020 40 Unix Figure: Disk layout, classical example November 10, 2020 Operating Systems 2020 41 Implementation („classical Unix“)I boot block: Boot Loader, to boot system super block: Infos on file system, e.g. size of partition block size pointer to free block list numberings of the root directory „magic number“ (identifies file system type) November 10, 2020 Operating Systems 2020 42 Implementation („classical Unix“) index nodes (inodes) 1:1-relation between inodes and files data blocks November 10, 2020 Operating Systems 2020 43 Index structure - inodes November 10, 2020 Operating Systems 2020 44 inodes November 10, 2020 Operating Systems 2020 45 InodeI Attributes: type (file, directory, character special
Recommended publications
  • IT1100 : Introduction to Operating Systems Chapter 15 What Is a Partition? What Is a Partition? Linux Partitions What Is Swap? M

    IT1100 : Introduction to Operating Systems Chapter 15 What Is a Partition? What Is a Partition? Linux Partitions What Is Swap? M

    IT1100 : Introduction to Operating Systems Chapter 15 What is a partition? A partition is just a logical division of your hard drive. This is done to put data in different locations for flexibility, scalability, ease of administration, and a variety of other reasons. One reason might be so you can install Linux and Windows side-by-side. What is a partition? Another reason is to encapsulate your data. Keeping your system files and user files separate can protect one or the otherfrom malware. Since file system corruption is local to a partition, you stand to lose only some of your data if an accident occurs. Upgrading and/or reformatting is easier when your personal files are stored on a separate partition. Limit data growth. Runaway processes or maniacal users can consume so much disk space that the operating system no longer has room on the hard drive for its bookkeeping operations. This will lead to disaster. By segregating space, you ensure that things other than the operating system die when allocated disk space is exhausted. Linux Partitions In Linux, a minimum of 1 partition is required for the / . Mounting is the action of connecting a filesystem/partition to a particular point in the / root filesystem. I.e. When a usb stick is inserted, it is assigned a particular mount point and is available to the filesytem tree. - In windows you might have an A:, or B:, or C:, all of which point to different filesystems. What is Swap? If RAM fills up, by running too many processes or a process with a memory leak, new processes will fail if your system doesn’t have a way to extend system memory.
  • A Dynamic Bitmap for Huge File System in Sans

    A Dynamic Bitmap for Huge File System in Sans

    A Dynamic Bitmap for Huge File System in SANs G.B.Kim*, D.J.Kang*, C.S.Park*, Y.J.Lee*, B.J.Shin** *Computer System Department, Computer and Software Technology Labs. ETRI(Electronics and Telecommunications Research Institute) 161 Gajong-Dong, Yusong-Gu, Daejon, 305-350, South Korea ** Dept. of Computer Engineering, Miryang National University 1025-1 Naei-dong Miryang Gyeongnam, South Korea Abstract: - A storage area network (SAN) is a high-speed special-purpose network (or subnetwork) that interconnects different kinds of data storage devices with associated data servers on behalf of a larger network of users. In SAN, computers service local file requests directly from shared storage devices. Direct device access eliminates the server machines as bottlenecks to performance and availability. Communication is unnecessary between computers, since each machine views the storage as being locally attached. SAN provides us to very large physical storage up to 64-bit address space, but traditional file systems can’t adapt to the file system for SAN because they have the limitation of scalability. In this paper we propose a new mechanism for file system using dynamic bitmap assignment. While traditional file systems rely on a fixed bitmap structures for metadata such as super block, inode, and directory entries, the proposed file system allocates bitmap and allocation area depend on file system features. Our approaches give a solution of the problem that the utilization of the file system depends on the file size in the traditional file systems. We show that the dynamic bitmap mechanism this improves the efficiency of disk usage in file system when compared to the conventional file systems.
  • File Formats

    File Formats

    man pages section 4: File Formats Sun Microsystems, Inc. 4150 Network Circle Santa Clara, CA 95054 U.S.A. Part No: 817–3945–10 September 2004 Copyright 2004 Sun Microsystems, Inc. 4150 Network Circle, Santa Clara, CA 95054 U.S.A. All rights reserved. This product or document is protected by copyright and distributed under licenses restricting its use, copying, distribution, and decompilation. No part of this product or document may be reproduced in any form by any means without prior written authorization of Sun and its licensors, if any. Third-party software, including font technology, is copyrighted and licensed from Sun suppliers. Parts of the product may be derived from Berkeley BSD systems, licensed from the University of California. UNIX is a registered trademark in the U.S. and other countries, exclusively licensed through X/Open Company, Ltd. Sun, Sun Microsystems, the Sun logo, docs.sun.com, AnswerBook, AnswerBook2, and Solaris are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. in the U.S. and other countries. Products bearing SPARC trademarks are based upon an architecture developed by Sun Microsystems, Inc. The OPEN LOOK and Sun™ Graphical User Interface was developed by Sun Microsystems, Inc. for its users and licensees. Sun acknowledges the pioneering efforts of Xerox in researching and developing the concept of visual or graphical user interfaces for the computer industry. Sun holds a non-exclusive license from Xerox to the Xerox Graphical User Interface, which license also covers Sun’s licensees who implement OPEN LOOK GUIs and otherwise comply with Sun’s written license agreements.
  • Where Do You Want to Go Today? Escalating

    Where Do You Want to Go Today? Escalating

    Where Do You Want to Go Today? ∗ Escalating Privileges by Pathname Manipulation Suresh Chari Shai Halevi Wietse Venema IBM T.J. Watson Research Center, Hawthorne, New York, USA Abstract 1. Introduction We analyze filename-based privilege escalation attacks, In this work we take another look at the problem of where an attacker creates filesystem links, thereby “trick- privilege escalation via manipulation of filesystem names. ing” a victim program into opening unintended files. Historically, attention has focused on attacks against priv- We develop primitives for a POSIX environment, provid- ileged processes that open files in directories that are ing assurance that files in “safe directories” (such as writable by an attacker. One classical example is email /etc/passwd) cannot be opened by looking up a file by delivery in the UNIX environment (e.g., [9]). Here, an “unsafe pathname” (such as a pathname that resolves the mail-delivery directory (e.g., /var/mail) is often through a symbolic link in a world-writable directory). In group or world writable. An adversarial user may use today's UNIX systems, solutions to this problem are typ- its write permission to create a hard link or symlink at ically built into (some) applications and use application- /var/mail/root that resolves to /etc/passwd. A specific knowledge about (un)safety of certain directories. simple-minded mail-delivery program that appends mail to In contrast, we seek solutions that can be implemented in the file /var/mail/root can have disastrous implica- the filesystem itself (or a library on top of it), thus providing tions for system security.
  • File Permissions Do Not Restrict Root

    File Permissions Do Not Restrict Root

    Filesystem Security 1 General Principles • Files and folders are managed • A file handle provides an by the operating system opaque identifier for a • Applications, including shells, file/folder access files through an API • File operations • Access control entry (ACE) – Open file: returns file handle – Allow/deny a certain type of – Read/write/execute file access to a file/folder by – Close file: invalidates file user/group handle • Access control list (ACL) • Hierarchical file organization – Collection of ACEs for a – Tree (Windows) file/folder – DAG (Linux) 2 Discretionary Access Control (DAC) • Users can protect what they own – The owner may grant access to others – The owner may define the type of access (read/write/execute) given to others • DAC is the standard model used in operating systems • Mandatory Access Control (MAC) – Alternative model not covered in this lecture – Multiple levels of security for users and documents – Read down and write up principles 3 Closed vs. Open Policy Closed policy Open Policy – Also called “default secure” • Deny Tom read access to “foo” • Give Tom read access to “foo” • Deny Bob r/w access to “bar” • Give Bob r/w access to “bar • Tom: I would like to read “foo” • Tom: I would like to read “foo” – Access denied – Access allowed • Tom: I would like to read “bar” • Tom: I would like to read “bar” – Access allowed – Access denied 4 Closed Policy with Negative Authorizations and Deny Priority • Give Tom r/w access to “bar” • Deny Tom write access to “bar” • Tom: I would like to read “bar” – Access
  • 21Files2.Pdf

    21Files2.Pdf

    Here is a portion of a Unix directory tree. The ovals represent files, the rectangles represent directories (which are really just special cases of files). A simple implementation of a directory consists of an array of pairs of component name and inode number, where the latter identifies the target file’s inode to the operating system (an inode is data structure maintained by the operating system that represents a file). Note that every directory contains two special entries, “.” and “..”. The former refers to the directory itself, the latter to the directory’s parent (in the case of the slide, the directory is the root directory and has no parent, thus its “..” entry is a special case that refers to the directory itself). While this implementation of a directory was used in early file systems for Unix, it suffers from a number of practical problems (for example, it doesn’t scale well for large directories). It provides a good model for the semantics of directory operations, but directory implementations on modern systems are more complicated than this (and are beyond the scope of this course). Here are two directory entries referring to the same file. This is done, via the shell, through the ln command which creates a (hard) link to its first argument, giving it the name specified by its second argument. The shell’s “ln” command is implemented using the link system call. Here are the (abbreviated) contents of both the root (/) and /etc directories, showing how /unix and /etc/image are the same file. Note that if the directory entry /unix is deleted (via the shell’s “rm” command), the file (represented by inode 117) continues to exist, since there is still a directory entry referring to it.
  • System Administration Storage Systems Agenda

    System Administration Storage Systems Agenda

    System Administration Storage Systems Agenda Storage Devices Partitioning LVM File Systems STORAGE DEVICES Single Disk RAID? RAID Redundant Array of Independent Disks Software vs. Hardware RAID 0, 1, 3, 5, 6 Software RAID Parity done by CPU FakeRAID Linux md LVM ZFS, btrfs ◦ Later Hardware RAID RAID controller card Dedicated hardware box Direct Attached Storage SAS interface Storage Area Network Fiber Channel iSCSI ATA-over-Ethernet Fiber Channel Network Attached Storage NFS CIFS (think Windows File Sharing) SAN vs. NAS PARTITIONING 1 File System / Disk? 2 TB maybe… 2TB x 12? 2TB x 128 then? Partitioning in Linux fdisk ◦ No support for GPT Parted ◦ GParted Fdisk Add Partition Delete Partition Save & Exit Parted Add Partition Change Units Delete Partition No need to save Any action you do is permanent Parted will try to update system partition table Script support parted can also take commands from command line: ◦ parted /dev/sda mkpart pri ext2 1Mib 10Gib Resize (Expand) 1. Edit partition table ◦ Delete and create with same start position 2. Reload partition table ◦ Reboot if needed 3. Expand filesystem Resize (Shrink) 1. Shrink filesystem ◦ Slightly smaller than final 2. Edit partition table ◦ Delete and create with same start position 3. Reload partition table ◦ Reboot if needed 4. Expand filesystem to fit partition No Partition Moving LOGICAL VOLUME MANAGER What is LVM? A system to manage storage devices Volume == Disk Why use LVM? Storage pooling Online resizing Resize any way Snapshots Concepts Physical Volume ◦ A disk or partition Volume Group ◦ A group of PVs Logical Volume ◦ A virtual disk/partition Physical Extent ◦ Data blocks of a PV Using a partition for LVM Best to have a partition table 1.
  • A Brief Technical Introduction

    A Brief Technical Introduction

    Mac OS X A Brief Technical Introduction Leon Towns-von Stauber, Occam's Razor LISA Hit the Ground Running, December 2005 http://www.occam.com/osx/ X Contents Opening Remarks..............................3 What is Mac OS X?.............................5 A New Kind of UNIX.........................12 A Diferent Kind of UNIX..................15 Resources........................................39 X Opening Remarks 3 This is a technical introduction to Mac OS X, mainly targeted to experienced UNIX users for whom OS X is at least relatively new This presentation covers primarily Mac OS X 10.4.3 (Darwin 8.3), aka Tiger X Legal Notices 4 This presentation Copyright © 2003-2005 Leon Towns-von Stauber. All rights reserved. Trademark notices Apple®, Mac®, Macintosh®, Mac OS®, Finder™, Quartz™, Cocoa®, Carbon®, AppleScript®, Bonjour™, Panther™, Tiger™, and other terms are trademarks of Apple Computer. See <http://www.apple.com/legal/ appletmlist.html>. NeXT®, NeXTstep®, OpenStep®, and NetInfo® are trademarks of NeXT Software. See <http://www.apple.com/legal/nexttmlist.html>. Other trademarks are the property of their respective owners. X What Is It? 5 Answers Ancestry Operating System Products The Structure of Mac OS X X What Is It? Answers 6 It's an elephant I mean, it's like the elephant in the Chinese/Indian parable of the blind men, perceived as diferent things depending on the approach X What Is It? Answers 7 Inheritor of the Mac OS legacy Evolved GUI, Carbon (from Mac Toolbox), AppleScript, QuickTime, etc. The latest version of NeXTstep Mach, Quartz (from Display PostScript), Cocoa (from OpenStep), NetInfo, apps (Mail, Terminal, TextEdit, Preview, Interface Builder, Project Builder, etc.), bundles, faxing from Print panel, NetBoot, etc.
  • Windows Task Scheduler – Privileges Escalation Vulnerability

    Windows Task Scheduler – Privileges Escalation Vulnerability

    CERT-EU Security Advisory 2018-024 Windows Task Scheduler – Privileges Escalation Vulnerability August 29, 2018 — v1.0 History: • 29/08/2018 — v1.0: Initial publication Summary On August 27th, a tweet from a researcher with a nick SandboxEscaper announced an unpatched local privileges escalation vulnerability in Windows. This flaw is affecting the way Task Sched- uler uses Advanced Local Procedure Call (ALPC) to read and set permissions. This allows a user with read access to an object to change his rights on it. Eventually, this vulnerability allows a user to run code with SYSTEM privileges. It is important to notice that a POC has been already published on Internet and there is no available patch yet [1, 2]. Technical Details The POC has been distributed with a text document giving some technical details about the exploit. This advisory is based on that [2]. The Windows Task Scheduler uses an ALPC method - SchRpcSetSecurity - to deal with the rights of the created tasks. As side effect, this function checks if a .job file exists under c:\windows\tasks and tries to set the permissions there too. Since all users have write per- mission there, an attacker can create a hard link in this folder in order to rewrite the privileges he has over other objects of the system. After that he can modify the object ending up with his code running as SYSTEM. This is the path followed by the POC with a DLL hijacking as outcome. It is important to note that this technique for rights rewriting could be used in other unforeseen ways.
  • Answers to Even-Numbered Exercises

    Answers to Even-Numbered Exercises

    4 Answers to Even-numbered Exercises 1. 2. List the commands you can use to perform these operations: a. Make your home directory the working directory b. Identify the working directory a. cd; b. pwd 3. 4. The df utility displays all mounted filesystems along with information about each. Use the df utility with the –h (human-readable) option to answer the following questions. $ df -h Filesystem Size Used Avail Capacity Mounted on /dev/disk2s10 20G 2.6G 17G 13% / devfs 114K 114K 0B 100% /dev fdesc 1.0K 1.0K 0B 100% /dev <volfs> 512K 512K 0B 100% /.vol /dev/disk0s9 77G 37G 39G 49% /Volumes/Scratch /dev/disk1s9 25G 16G 9.5G 63% /Volumes/Sys /dev/disk2s12 94G 43M 94G 0% /Volumes/New /dev/disk1s10 86G 71G 15G 83% /Volumes/Home automount -nsl [223] 0B 0B 0B 100% /Network automount -fstab [232] 0B 0B 0B 100% /automount/Servers automount -static [232] 0B 0B 0B 100% /automount/static a. How many filesystems are mounted on your Mac OS X system? b. Which filesystem stores your home directory? c. Assuming that your answer to exercise 4a is two or more, attempt to create a hard link to a file on another filesystem. What error message do you get? What happens when you attempt to create a symbolic link to the file instead? 1 2 Answers to Even-numbered Exercises Following are sample answers to these questions. Your answers will be different because your filesystem is different. a. five; b. /dev/disk2s10; c. ln: xxx: Cross-device link. No problem creating a cross-device symbolic link.
  • File System (Interface)

    File System (Interface)

    File System (Interface) Dave Eckhardt [email protected] 1 Synchronization Today Chapter 11, File system interface Not: remote/distributed (11.5.2!!) Don't forget about Chapter 13 Reviewing might help demystify readline() some “Fourth Wave” of readings posted to web site 2 Synchronization Two interesting papers about disks http://www.seagate.com/content/docs/pdf/whitepaper/ D2c_More_than_Interface_ATA_vs_SCSI_042003.p df Google for “200 ways to revive a hard drive” 3 What's a file? Abstraction of persistent storage Hide details of storage devices sector addressing: CHS vs. LBA SCSI vs. IDE Logical grouping of data May be physically scattered Programs, data Some internal structure 4 Typical file attributes Name – 14? 8.3? 255? Unicode? ASCII? 6-bit? RADIX-50? Identifier - “file number” Type (or not) Location – device, location Size – real or otherwise Protection – Who can do what? Time, date, last modifier – monitoring, curiousity 5 “Extended” file attributes BSD Unix archived nodump append-only (user/system) immutable (user/system) MacOS icon color 6 Operations on Files Create – locate space, enter into directory Write, Read – according to position pointer/cursor Seek – adjust position pointer Delete – remove from directory, release space Truncate Trim data from end Often all of it Append, Rename 7 Open-file State Expensive to specify name for each read()/write() String-based operation Directory look-up “Open-file” structure stores File-system / partition File-system-relative file number Read vs. write Cursor position 8 Open files (Unix Model) “In-core” / “Open file” file state Mirror of on-disk structure File number, size, permissions, modification time, ... Housekeeping info Back pointer to containing file system #readers, #writers Most-recently-read block How to access file (vector of methods) Pointer to file's type-specific data Shared when file is opened multiple times 9 Open files (Unix Model) “File-open” state (result of one open() call) Access mode (read vs.
  • Z/VM Version 7 Release 2

    Z/VM Version 7 Release 2

    z/VM Version 7 Release 2 OpenExtensions User's Guide IBM SC24-6299-01 Note: Before you use this information and the product it supports, read the information in “Notices” on page 201. This edition applies to Version 7.2 of IBM z/VM (product number 5741-A09) and to all subsequent releases and modifications until otherwise indicated in new editions. Last updated: 2020-09-08 © Copyright International Business Machines Corporation 1993, 2020. US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Contents Figures................................................................................................................. xi Tables................................................................................................................ xiii About this Document........................................................................................... xv Intended Audience..................................................................................................................................... xv Conventions Used in This Document......................................................................................................... xv Escape Character Notation................................................................................................................... xv Case-Sensitivity.....................................................................................................................................xv Typography............................................................................................................................................xv