Week 12 - Friday.  What did we talk about last time?  Exam 2 post mortem.

Slides:



Advertisements
Similar presentations
Concepts about the file system 2. The disk structure 3. Files in disk – The ext2 FS 4. The Virtual File System (c) 2013, Prof. Jordi Garcia.
Advertisements

© Original by Donald Acton; Changes by George Tsiknis Unix I/O Related Text Sections: 2nd Ed: and st Ed: and
January 13, Csci 2111: Data and File Structures Week1, Lecture 2 Basic File Processing Operations.
File Systems Examples.
CS 241 Section Week #5 2/23/12. 2 Topics This Section MP4 overview Function Pointers Pthreads File I/O.
Ext2/Ext3 Linux File System Reporter: Po-Liang, Wu.
1 Files and Directories Hua LiSystems ProgrammingCS2690Files and Directories.
Today’s topic: –File operations –I/O redirection –Inter-process communication through pipes.
System-Level I/O Topics Unix I/O Robust reading and writing Reading file metadata Sharing files I/O redirection Standard I/O.
CS 311 – Lecture 09 Outline Introduction to Systems programming – System calls – Categories of system calls Error Management System calls File Handling.
Files. System Calls for File System Accessing files –Open, read, write, lseek, close Creating files –Create, mknod.
1 Advanced programming in UNIX 1 File I/O Hua LiSystems ProgrammingCS2690File I/O.
I/O April 16, 2002 Topics Files Unix I/O Standard I/O Reading: (Beta) or (New) Problems: 12.9 (Beta) or 12.4 (New) class24.ppt
Accessing Files in CCS-2303, C-Term Accessing Files in C CS-2303 System Programming Concepts (Slides include materials from The C Programming Language,
CS 311 – Lecture 12 Outline File management system calls Stat() Directory Information  Opendir()  Readdir()  Closedir() Truncate() and remove() Lecture.
NCHU System & Network Lab Lab 13 File I/O & Standard I/O.
1 Unix File System API Operating System Hebrew University Spring 2007.
Today’s topic: –File operations –I/O redirection –Inter-process communication through pipes.
POSIX: Files Introduction to Operating Systems: Discussion 1 Read Solaris System Interface Guide: Ch. 5.1 Basic File I/O.
Chapter 39 Virtsualization of Storage: File and Directory Chien-Chung Shen CIS, UD
Adv. UNIX: lowIO/161 Advanced UNIX v Objectives –look at low-level operations for handling files Special Topics in Comp. Eng. 2 Semester.
1Fall 2008, Chapter 11 Disk Hardware Arm can move in and out Read / write head can access a ring of data as the disk rotates Disk consists of one or more.
Input and Output Topics I/O hardware Unix file abstraction Robust I/O File sharing io.ppt CS 105 “Tour of the Black Holes of Computing”
Fundamentals CIS 552. Fundamentals Low-level I/O (read/write using system calls)  Opening/Creating files  Reading & Writing files  Moving around in.
1 System-Level I/O Andrew Case Slides adapted from Jinyang Li, Randy Bryant and Dave O’Hallaron.
Week 12 - Friday.  What did we talk about last time?  Exam 2 post mortem  Low level file I/O.
File System Implementation Chapter 12. File system Organization Application programs Application programs Logical file system Logical file system manages.
Operating Systems Recitation 1, March th, 2002.
Chapter 5 File Management File System Implementation.
CS252: Systems Programming Ninghui Li Based on Slides by Prof. Gustavo Rodriguez-Rivera Topic 8: Opening Files and Starting Processes.
UNIX Files File organization and a few primitives.
Files & File system. A Possible File System Layout Tanenbaum, Modern Operating Systems 3 e, (c) 2008 Prentice-Hall, Inc. All rights reserved
Files and Directories File types stat functions for file information
Week 12 - Wednesday.  What did we talk about last time?  File I/O  Binary trees  Lab 11.
Project 6 Unix File System. Administrative No Design Review – A design document instead 2-3 pages max No collaboration with peers – Piazza is for clarifications.
Today’s topic Access and manipulate meta data for files –File type, ownership, access permissions, access time, etc How to determine if a file is not there?
CSCI 330 UNIX and Network Programming Unit VII: I/O Management I.
File Systems cs550 Operating Systems David Monismith.
Laface 2007 File system 2.1 Operating System Design Filesystem system calls buffer allocation algorithms getblk brelse bread breada bwrite iget iput bmap.
NCHU System & Network Lab Lab 14 File and Directory.
CSE333 SECTION 3. Important Dates Jan 27 th – Homework 1 Due Feb 6 th – Midterm.
NTFS Filing System CHAPTER 9. New Technology File System (NTFS) Started with Window NT in 1993, Windows XP, 2000, Server 2003, 2008, and Window 7 also.
January 7, 2003Serguei Mokhov, 1 File I/O System Calls Reference COMP 229, 444, 5201 Revision 1.2 Date: July 21, 2004.
Copyright ©: Nahrstedt, Angrave, Abdelzaher1 Tarek Abdelzaher Vikram Adve CS241 Systems Programming System Calls and I/O.
Library Functions The UNIX system provides a large number of C functions as libraries. Some of these implement frequently used operations, while others.
1 System-Level I/O. 2 Outline Unix I/O Reading File Metadata Sharing Files & I/O redirection Robust I/O Standard I/O Suggested Reading –10.1~10.3, 10.5~10.7,
File I/O open close lseek read and write – unbuffered I/O dup and dup2.
CSC 660: Advanced Operating SystemsSlide #1 CSC 660: Advanced OS Virtual Filesystem.
CSCI 330 UNIX and Network Programming Unit VIII: I/O Management II.
I/O Software CS 537 – Introduction to Operating Systems.
File Subsystem in Linux by Dr P.Padmanabham Professor (CSE)&Director Bharat Institute of Engineering &Technology Hyderabad Mobile
Files Oct. 28, 2008 Topics Mapping file offsets to disk blocks File system buffering and you The directory hierarchy lecture-18.ppt “The course.
CSC 271 – Software I: Utilities and Internals An Introduction to File I/O in Linux Credited to Dr. Robert Siegfried and Beginning Linux Programming by.
CSCE Systems Programming Lecture 07 – Make, Stdio, I/O Buffering CSCE 510 Jan 23, 2013.
File System Department of Computer Science Southern Illinois University Edwardsville Spring, 2016 Dr. Hiroshi Fujinoki CS 314.
File table: a list of opened files Each entry contains: – Index: file descriptors – Pointer to the file in memory – Access mode File descriptor is a positive.
File-System Management
Week 12 - Thursday CS222.
Week 12 - Wednesday CS222.
Files I/O, Streams, I/O Redirection, Reading with fscanf
Operating System Hebrew University Spring 2004
“The course that gives CMU its Zip!”
File Structure Related system calls
“The course that gives CMU its Zip!”
Accessing Files in C Professor Hugh C. Lauer CS-2303, System Programming Concepts (Slides include materials from The C Programming Language, 2nd edition,
File I/O (1) Prof. Ikjun Yeom TA – Hoyoun
Advanced UNIX progamming
Chien-Chung Shen CIS, UD
Chapter 12: File-System Implementation CSS503 Systems Programming
Week 12 - Wednesday CS222.
Presentation transcript:

Week 12 - Friday

 What did we talk about last time?  Exam 2 post mortem

Programs must be written for people to read and only incidentally for machines to execute. Harold Abelson and Gerald Jay Sussman Authors of The Structure and Interpretation of Computer Programs Programs must be written for people to read and only incidentally for machines to execute. Harold Abelson and Gerald Jay Sussman Authors of The Structure and Interpretation of Computer Programs

 You just learned how to read and write files  Why are we going to do it again?  There is a set of Unix/Linux system commands that do the same thing  Most of the higher level calls ( fopen(), fprintf(), fgetc(), and even trusty printf() ) are built on top of these low level I/O commands  These give you direct access to the file system (including pipes)  They are often more efficient  You'll use the low-level file style for networking  All low level I/O is binary

 To use low level I/O functions, include headers as follows: #include  You won't need all of these for every program, but you might as well throw them all in

 High level file I/O uses a FILE* variable for referring to a file  Low level I/O uses an int value called a file descriptor  These are small, nonnegative integers  Each process has its own set of file descriptors  Even the standard I/O streams have descriptors StreamDescriptorDefined Constant stdin0STDIN_FILENO stdout1STDOUT_FILENO stderr2STDERR_FILENO

 To open a file for reading or writing, use the open() function  There used to be a creat() function that was used to create new files, but it's now obsolete  The open() function takes the file name, an int for mode, and an (optional) int for permissions  It returns a file descriptor int fd = open("input.dat", O_RDONLY);

 The main modes are  O_RDONLY Open the file for reading only  O_WRONLY Open the file for writing only  O_RDWR Open the file for both  There are many other optional flags that can be combined with the main modes  A few are  O_CREAT Create file if it doesn’t already exist  O_DIRECTORY Fail if pathname is not a directory  O_TRUNC Truncate existing file to zero length  O_APPEND Writes are always to the end of the file  These flags can be combined with the main modes (and each other) using bitwise OR int fd = open("output.dat", O_WRONLY | O_CREAT | O_APPEND );

 Because this is Linux, we can also specify the permissions for a file we create  The last value passed to open() can be any of the following permission flags bitwise ORed together  S_IRUSR User read  S_IWUSR User write  S_IXUSR User execute  S_IRGRP Group read  S_IWGRP Group write  S_IXGRP Group execute  S_IROTH Other read  S_IWOTH Other write  S_IXOTH Other execute int fd = open("output.dat", O_WRONLY | O_CREAT | O_APPEND, S_IRUSR | S_IRGRP );

 Opening the file is actually the hardest part  Reading is straightforward with the read() function  Its arguments are  The file descriptor  A pointer to the memory to read into  The number of bytes to read  Its return value is the number of bytes successfully read int fd = open("input.dat", O_RDONLY); int buffer[100]; read( fd, buffer, sizeof(int)*100 ); //fill with something int fd = open("input.dat", O_RDONLY); int buffer[100]; read( fd, buffer, sizeof(int)*100 ); //fill with something

 Writing to a file is almost the same as reading  Arguments to the write() function are  The file descriptor  A pointer to the memory to write from  The number of bytes to write  Its return value is the number of bytes successfully written int fd = open("output.dat", O_WRONLY); int buffer[100]; int i = 0; for( i = 0; i < 100; i++ ) buffer[i] = i + 1; write( fd, buffer, sizeof(int)*100 ); int fd = open("output.dat", O_WRONLY); int buffer[100]; int i = 0; for( i = 0; i < 100; i++ ) buffer[i] = i + 1; write( fd, buffer, sizeof(int)*100 );

 To close a file descriptor, call the close() function  Like always, it's a good idea to close files when you're done with them int fd = open("output.dat", O_WRONLY); //write some stuff close( fd ); int fd = open("output.dat", O_WRONLY); //write some stuff close( fd );

 It's possible to seek with low level I/O using the lseek() function  Its arguments are  The file descriptor  The offset  Location to seek from: SEEK_SET, SEEK_CUR, or SEEK_END int fd = open("input.dat", O_RDONLY); lseek( fd, 100, SEEK_SET ); int fd = open("input.dat", O_RDONLY); lseek( fd, 100, SEEK_SET );

 Use low level I/O to write a hex dump program  Print out the bytes in a program, 16 at a time, in hex, along with the current offset in the file, also in hex  Sample output: 0x : 7f 45 4c x : c x : e x : 1d 00 1a x : 7f 45 4c x : c x : e x : 1d 00 1a

 In Linux, files can be opened by multiple processes at the same time  Doing so carelessly can lead to race conditions  The contents of the file depend on how the programs were scheduled by the OS  All system calls ( open(), read(), etc.) are atomic  They will execute completely and won't be interrupted by another process

 A file descriptor is not necessarily unique  Not even in the same process  It's possible to duplicate file descriptors  Thus, the output to one file descriptor also goes to the other  Input is similar

 stderr usually prints to the screen, even if stdout is being redirected to a file  What if you want stderr to get printed to that file as well?  You can also redirect only stderr to a file./program > output.txt./program > output.txt 2>&1./program 2> errors.log

 If you want a new file descriptor number that refers to an open file descriptor, you can use the dup() function  It's often more useful to change an existing file descriptor to refer to another stream, which you can do with dup2()  Now all writes to stderr will go to stdout int fd = dup(1); //makes a copy of stdout dup2(1, 2); //makes 2 (stderr) a copy of 1 (stdout) dup2(1, 2); //makes 2 (stderr) a copy of 1 (stdout)

 Reading from and writing to files on a hard drive is expensive  These operations are buffered so that one big read or write happens instead of lots of little ones  If another program is reading from a file you've written to, it reads from the buffer, not the old file  Even so, it is more efficient for your code to write larger amounts of data in one pass  Each system call has overhead

 To avoid having too many system calls, stdio uses this second kind of buffering  This is an advantage of stdio functions rather than using low-level read() and write() directly  The default buffer size is 8192 bytes  The setvbuf(), setbuf(), and setbuffer() functions let you specify your own buffer

 Stdio output buffers are generally flushed (sent to the system) when they hit a newline ( '\n' ) or get full  When debugging code that can crash, make sure you put a newline in your printf(), otherwise you might not see the output before the crash  There is an fflush() function that can flush stdio buffers fflush(stdout); //flushes stdout //could be any FILE* fflush(NULL); //flushes all buffers fflush(stdout); //flushes stdout //could be any FILE* fflush(NULL); //flushes all buffers

 Until SSDs take over, physical hard drives are mostly electronically controlled spinning platters with magnetic coatings  Disks have circular tracks divided into sectors which contain blocks  A block is the smallest amount of information a disk can read or write at a time  Physical disks are partitioned into logical disks  Each partition is treated like a separate device in Linux  And a separate drive ( C:, D:, E:, etc.) in Windows  Each partition can have its own file system

 Linux supports a lot of file systems  ext2, the traditional Linux file system  Unix ones like the Minix, System V, and BSD file systems  Microsoft’s FAT, FAT32, and NTFS file systems  The ISO 9660 CD-ROM file system  Apple's HFS  Network file systems, including Sun’s widely used NFS  A range of journaling file systems, including ext3, ext4, Reiserfs, JFS, XFS, and Btrfs  And more!

 Virtually all file systems have each partition laid out something like this  The boot block is the first block and has information needed to boot the OS  The superblock has information about the size of the i-node table and logical blocks  The i-node table has entries for every file in the system  Data blocks are the actual data in the files and take up almost all the space Boot blockSuperblocki-node TableData blocks

 Every file has an i-node in the i-node table  Each i-node has information about the file like type (directory or not), owner, group, permissions, and size  More importantly, each i-node has pointers to the data blocks of the file on disk  In ext2, i-nodes have 15 pointers  The first 12 point to blocks of data  The next points to a block of pointers to blocks of data  The next points to a block of pointers to pointers to blocks of data  The last points to a block of pointers to pointers to pointers to blocks of data

 If a regular file system (like ext2) crashes, it might be in an inconsistent state  It has to look through all its i-nodes to try to repair inconsistent data  A journaling file system (like ext3, ext4, and Reiserfs) keeps metadata about the operations it's trying to perform  These operations are called transactions  After a crash, the file system only needs to repair those transactions that weren't completed

 Files have many attributes, most of which are stored in their i-node  These attributes include:  Device (disk) the file is on  i-node number  File type and permissions  Owner and group  Size  Times of last access, modification, and change  There are functions that will let us retrieve this information in a C program  stat(), lstat(), and fstat()

 Attributes can be stored in a stat structure struct stat { dev_t st_dev; /* IDs of device on which file resides */ ino_t st_ino; /* I-node number of file */ mode_t st_mode; /* File type and permissions */ nlink_t st_nlink; /* Number of (hard) links to file */ uid_t st_uid; /* User ID of file owner */ gid_t st_gid; /* Group ID of file owner */ dev_t st_rdev; /* IDs for device special files */ off_t st_size; /* Total file size (bytes) */ blksize_t st_blksize; /* Optimal block size for I/O (bytes)*/ blkcnt_t st_blocks; /* Number of (512B) blocks allocated */ time_t st_atime; /* Time of last file access */ time_t st_mtime; /* Time of last file modification */ time_t st_ctime; /* Time of last status change */ }; struct stat { dev_t st_dev; /* IDs of device on which file resides */ ino_t st_ino; /* I-node number of file */ mode_t st_mode; /* File type and permissions */ nlink_t st_nlink; /* Number of (hard) links to file */ uid_t st_uid; /* User ID of file owner */ gid_t st_gid; /* Group ID of file owner */ dev_t st_rdev; /* IDs for device special files */ off_t st_size; /* Total file size (bytes) */ blksize_t st_blksize; /* Optimal block size for I/O (bytes)*/ blkcnt_t st_blocks; /* Number of (512B) blocks allocated */ time_t st_atime; /* Time of last file access */ time_t st_mtime; /* Time of last file modification */ time_t st_ctime; /* Time of last status change */ };

 I really shouldn't tell you about these  But there are functions that can change the timestamp of a file  utime() lets you change the access and modification times for a file, with units in seconds  utimes() lets you do the same thing, but with accuracy in microseconds

 Networking overview  Sockets

 Finish Project 5  Due tonight by midnight  Read LPI Chapters 56, 57, 58, and 59