read(2) There can be several cases where read returns less than the number of bytes requested:

Transcription

1 read(2) There can be several cases where read returns less than the number of bytes requested: EOF reached before requested number of bytes have been read Reading from a terminal device, one line read at a time Reading from a network, buffering can cause delays in arrival of data Reading from a pipe or FIFO, pipe can contain fewer bytes than requested Record-oriented devices (magtape) may return data one record at a time Interruption by a signal read begins reading at the current offset, and increments the offset by the number of bytes actually read. File I/O 1

2 write(2) write returns nbytes or an error has occurred A common cause for a write error is either filling up a disk or exceeding the file size limit for a given process For regular files, write begins writing at the current offset (unless O_APPEND has been specified, in which case the offset is first set to the end of the file) After the write, the offset is adjusted by the number of bytes actually written File I/O 2

3 I/O Efficiency File I/O 3

4 I/O Efficiency File I/O 4

5 File Sharing Since UNIX is a multi-user/multi-tasking system, it is conceivable (and useful) if more than one process can act on a single file simultaneously. In order to understand how this is accomplished, we need to examine some kernel data structures which relate to files. File I/O 5

6 File Sharing Each process table entry has a table of file descriptors, which contain the file descriptor flags (i.e. FD_CLOEXEC, see fcntl(2)) a pointer to a file table entry The kernel maintains a file table; each entry contains file status flags (O_APPEND, O_SYNC, O_RDONLY, etc.) current file offset pointer to the vnode table entry A vnode structure contains information about the type of the file and pointers to functions that operate on the file. This information is read from disk when the file is opened. vnode information inode information (such as current file size) * ) Linux uses a file system independent i-node and a file system dependent i-node. File I/O 6

7 Kernel Data structures for File I/O File I/O 7

8 File Sharing File I/O 8

9 File Sharing Knowing this, here s what happens with each of the calls we discussed earlier: After each write completes, the current file offset in the file table entry is incremented. (If current file offset > current file size, change current file size in i-node table entry.) If file was opened O_APPEND set corresponding flag in file status flags in file table. For each write, current file offset is first set to current file size from the i-node entry. lseek simply adjusts current file offset in file table entry to lseek to the end of a file, just copy current file size into current file offset. File I/O 9

10 Atomic Operations In order to ensure consistency across multiple writes, we require atomicity in some operations. An operation is atomic if either all of the steps are performed or none of the steps are performed. Suppose UNIX didn t have O_APPEND (early versions didn t). To append, you d have to do this: What if another process was doing the same thing to the same file? Any operation that requires more than one function call cannot be atomic File I/O 10

11 pread(2) and pwrite(2) Atomic read/write at offset without invoking lseek(2). Current offset is not updated. File I/O 11

12 Creating a File If we don t have the options O_CREAT and O_EXCL for open function, we might try The problem occurs if the file is created by another process between the open and the creat. File I/O 12

13 dup(2) and dup2(2) An existing file descriptor can be duplicated with dup(2) or duplicated to a particular file descriptor value with dup2(2). As with open(2), dup(2) returns the lowest numbered unused file descriptor. With dup2(2), we specify the value of the new descriptor with the fd2 argument. If fd2 is already open, it is first closed. If fd equals fd2, then dup2 returns fd2 without closing it. Otherwise, the FD_CLOEXEC file descriptor flag is cleared for fd2, so that fd2 is left open if the process calls exec. File I/O 13

14 Kernel data structures after dup(2) File I/O 14

15 sync(2), fsync(2), and fdatasync(2) To ensure consistency of the file system against delayed-writes sync(2) queues all the modified block buffers for writing and returns. fsync(2) refers only to a single file, and waits for the disk writes to complete before returning. fdatasync(2) is similar to fsync(2), but it affects only the data portions of a file. File I/O 15

16 fcntl(2) fcntl(2) is used for five different purposes: Duplicate an existing descriptor (cmd = F_DUPFD or F_DUPFD_CLOEXEC) Get/set file descriptor flags (cmd = F_GETFD or F_SETFD) Get/set file status flags (cmd = F_GETFL or F_SETFL) Get/set asynchronous I/O ownership (cmd = F_GETOWN or F_SETOWN) Get/set record locks (cmd = F_GETLK, F_SETLK, or F_SETLKW) File I/O 16

17 File status flags for fcntl(2) *) Because the five access-mode flags are not separate bits, we must first use the O_ACCMODE mask to obtain the access-mode bits and then compare the result against any of the five values. File I/O 17

18 File I/O 18

19 File I/O 19

20 We can change the middle statement to: File I/O 20

21 Timings with O_SYNC flags File I/O 21

22 ioctl(2) Another catch-all function, this one is designed to handle device specifics that can t be specified via any of the previous function calls. For example, terminal I/O, magtape access, socket I/O, etc. Mentioned here mostly for completeness s sake. File I/O 22

23 /dev/fd Modern systems provide a directory named /dev/fd whose entries are files named 0, 1, 2, and so on. Opening the file /dev/fd/n is equivalent to duplicating descriptor n, assuming that descriptor n is open. Some systems provide the pathnames /dev/stdin, /dev/stdout, and /dev/stderr. These pathnames are equivalent to /dev/fd/0, /dev/fd/1, and /dev/fd/2, respectively. The main use of the /dev/fd files is from the shell. File I/O 23

24 Questions? File I/O 24