Steve Pate : Файловая система UNIX : эволюция , разработка , реализация

Файловые концепции

Эта глава обьясняет основные концепции. Начинающие программисты юникса найдут здесь много полезного. Подробно будет рассмотрена реализация известной утилиты ls , связанные с ней библиотеки и системные вызовы.

Как известно , в UNIX буквально все представляет из себя файл , и все операции сводятся к операциям файлового типа. Открыть и прочитать директорию можно в том же порядке , что и открыть и прочитать файл.

Типы файлов UNIX

Каталоги предназначены для организации файловой системы в иерархическую структуру.

Существуют и другие типы файлов :

Regular files. Такие файлы хранят данные различного типа , и такие файлы никак особо не интерпретируются файловой системой.

Directories. Придают структурированность файловой системе. Каталоги могут индексировать входящие в них файлы в произвольном порядке.

Symbolic links. Символическая ссылка , называемая также симлинком - symlink - означает , что один файл может ссылаться на другой файл с другим именем. Удаление симлинка никак не влияет на ссылаемый файл.

Hard links. Такой линк отличается от симлинка тем , что имеет счетчик , который увеличивается каждый раз на единицу при его создании. При каждом удалении такого линка счетчик уменьшается на единицу. Когда счетчик становится равным нулю , источник ссылки удаляется.

Named pipes. Именованный канал - это дву-направленный IPC (Inter Process Communication) механизм , который связывает 2 процесса. Отличается от обычных UNIX pipes тем , что доступ к ним имеет ограничение.

Special files. Специальный файл ссылается на устройство типа диска. Для доступа к такому устройству нужно открыть специальный файл.

Xenix special file. Семафоры и расшаренные сегменты памяти в операционной системе Xenix могут управляться из UNIX. Специальный файл нулевой длины может быть представлен как семафор или сегмент памяти.

Для получения свойств файла любого типа может быть вызван системный вызов stat(). Он неявно вызывается в утилите ls .

Файловые дескрипторы

 #include < sys/types.h>
 #include < sys/stat.h>
 #include < fcntl.h>
 
 main(
 int fd;
 
  fd = open("/etc/passwd", O_RDONLY)
 printf("fd = %d\n", fd)
 close(fd)
 
 
 $ make open
 cc open.c -o open
 $ ./open
 fd = 3
 

 int open(const char *path, int oflag, ...)
 
 DESCRIPTION
 The open() function establishes the connection between 
 file and a file descriptor. It creates an ..
 
 

Базовые свойства файла

 Файловый тип и доступ
 Число линков на этот файл
 Владельца и группу
 Размер файла
 Дата последней модификации
 Имя файла
 

 1. Выводит файлы текущей директории
 2. Для каждого файла выводит его свойства
 

 #include < sys/types.h>
 #include < sys/stat.h>
 
 int stat(const char *path, struct stat *buf)
 
 - -regular file 
 d -directory 
 s -symbolic link 
 p -named pipe 
 c -character special 
 b -block special file name 
 

 
 struct stat {
 	dev_t st_dev; /* ID of device containing file */ 
 	ino_t st_ino; /* Inode number / file serial number */ 
 	mode_t st_mode; /* File mode */ 
 	nlink_t st_nlink; /* Number of links to file */ 
 	uid_t st_uid; /* User ID of file */ 
 	gid_t st_gid; /* Group ID of file */ 
 	dev_t st_rdev; /* Device ID for char/blk special file */ 
 	off_t st_size; /* File size in bytes (regular file) */ 
 	time_t st_atime; /* Time of last access */ 
 	time_t st_mtime; /* Time of last data modification */ 
 	time_t st_ctime; /* Time of last status change */ 
 	long st_blksize; /* Preferred I/O block size */ 
 	blkcnt_t st_blocks; /* Number of 512 byte blocks allocated */ 
 }; 
 

 1 #include < sys/types.h>
 2 #include < sys/stat.h>
 3 #include < sys/dirent.h>
 4 #include < sys/unistd.h>
 5 #include < fcntl.h>
 6 #include < unistd.h>
 7 #include < errno.h>
 8 #include < pwd.h>
 9 #include < grp.h>
 10
 11 #define BUFSZ 1024
 12
 13 main(
 14 { 
 15 struct dirent *dir; 
 16 struct stat st; 
 17 struct passwd *pw; 
 18 struct group *grp; 
 19 char buf[BUFSZ], *bp, *ftime; 
 20 int dfd, fd, nread; 
 21 
 22 dfd = open(".", O_RDONLY)
 23 bzero(buf, BUFSZ)
 24 while (nread = getdents(dfd, (struct dirent *)&buf,
 25 BUFSZ) != 0) 
 26 bp = buf;
 27 dir = (struct dirent *)buf;
 28 do 
 29 if (dir->d_reclen != 0) 
 30 stat(dir->d_name, &st)
 31 ftime = ctime(&st.st_mtime)
 32 ftime[16] = '\0'; ftime += 4;
 33 pw = getpwuid(st.st_uid)
 34 grp = getgrgid(st.st_gid)
 35 perms(st.st_mode)
 36 printf("%3d %-8s %-7s %9d %s %s\n"
 37 st.st_nlink, pw->pw_name, grp->gr_name,
 38 st.st_size, ftime, dir->d_name)
 39 
 40 bp = bp + dir->d_reclen;
 41 dir = (struct dirent *)(bp)
 42 } while (dir->d_ino != 0)
 43 bzero(buf, BUFSZ)
 44 
 45 
 

В цикле системный вызов getdents() будет вызван столько раз , сколько там окажется файлов. Программу вообще-то надо-бы потестировать для большого количества файлов.

В дополнение к системному вызову stat() есть еще два , которые дают аналогичный результат:

 #include < sys/types.h>
 #include < sys/stat.h>
 
 int lstat(const char *path, struct stat *buf)
 
 int fstat(int fildes, struct stat *buf)
 

Маска создания файла

 $ touch myfile
 $ ls -l myfile
 -rw-r--r-1 spate fcf 0 Feb 16 11:14 myfile
 

К файлу будут привязаны id-шники пользователя и группы пользователей. Он доступен на чение-запись (rw-) владельцем и членами группыg fcf.

Если вы хотите изменить свойства файла , для этого есть команда umask.

Маску файла можно вывести в числовой или символьной форме :

 $ umask
 022
 $ umask -
 u=rwx,g=rx,o=rx
 

Маска по умолчанию для вновь созданного файла как правтло = 022 при создании с помощью touch:

 $ umask
 022
 $ strace touch myfile 2>&1 | grep open | grep myfile
 open("myfile"
 O_WRONLY_O_NONBLOCK_O_CREAT_O_NOCTTY_O_LARGEFILE, 0666) = 
 $ ls -l myfile
 -rw-r--r-1 spate fcf 0 Apr 4 09:45 myfile
 

Изменение атрибутов файла

 chmod [ -fR ]  file ... 
 chmod [ -fR ]  file ... 
 

 $ ls -l myfile
 -rw------1 spate fcf 0 Mar 6 10:09 myfile
 $ chmod 744 myfile
 $ ls -l myfile
 -rwxr--r-1 spate fcf 0 Mar 6 10:09 myfile*
 

 
 $ ls -l myfile
 -rw------1 spate fcf 0 Mar 6 10:09 myfile
 $ chmod u+x,a+r myfile
 $ ls -l myfile
 -rwxr--r-1 spate fcf 0 Mar 6 10:09 myfile*
 

 $ ls -l myfile
 -rw------1 spate fcf 0 Mar 6 10:09 myfile
 $ chmod u=rwx,g=r,o=r myfile
 $ ls -l myfile
 -rwxr--r-1 spate fcf 0 Mar 6 10:09 myfile*
 

 $ ls -ld mydir
 drwxr-xr-x 2 spate fcf 4096 Mar 30 11:06 mydir/
 $ ls -l mydir
 total 
 -rw-r--r-1 spate fcf 0 Mar 30 11:06 fileA
 -rw-r--r-1 spate fcf 0 Mar 30 11:06 fileB
 $ chmod -R a+w mydir
 $ ls -ld mydir
 drwxrwxrwx 2 spate fcf 4096 Mar 30 11:06 mydir/
 $ ls -l mydir
 total 
 -rw-rw-rw 1 spate fcf 0 Mar 30 11:06 fileA
 -rw-rw-rw 1 spate fcf 0 Mar 30 11:06 fileB
 

 $ find mydir -print | xargs chmod a+
 

 #include < sys/types.h>
 #include < sys/stat.h>
 
 int chmod(const char *path, mode_t mode)
 
 
 int fchmod(int fildes, mode_t mode)
 

 
 	S_IRWXU. This is the bitwise OR of S_IRUSR, S_IWUSR and S_IXUSR 
 	S_IRWXG. This is the bitwise OR of S_IRGRP, S_IWGRPand S_IXGRP 
 	S_IRWXO. This is the bitwise OR of S_IROTH, S_IWOTH and S_IXOTH 
 

Изменение владельца файла

There are three calls that can be used to change the files user and group as shown below:

 #include < sys/types.h>
 #include < unistd.h>
 
 int chown(const char *path, uid_t owner, gid_t group)
 int fchown(int fd, uid_t owner, gid_t group)
 int lchown(const char *path, uid_t owner, gid_t group)
 

 
 
 
 PERMISSION DESCRIPTION 
 Table 2.1 Permissions Passed to chmod() 
 
 S_IRWXU Read, write, execute/search by owner 
 S_IRUSR Read permission by owner 
 S_IWUSR Write permission by owner 
 S_IXUSR Execute/search permission by owner 
 S_IRWXG Read, write, execute/search by group 
 S_IRGRP Read permission by group 
 S_IWGRP Write permission by group 
 S_IXGRP Execute/search permission by group 
 S_IRWXO Read, write, execute/search by others 
 S_IROTH Read permission by others 
 S_IWOTH Write permission by others 
 S_IXOTH Execute/search permission by others 
 S_ISUID Set-user-ID on execution 
 S_ISGID Set-group-ID on execution 
 S_ISVTX On directories, set the restricted deletion flag 
 

 
 $ ls -l /etc/passwd
 -r--r--r-1 root other 157670 Mar 14 16:03 /etc/passwd
 $ ls -l /usr/bin/passwd
 -r-sr-sr-x 3 root sys 99640 Oct 6 1998 /usr/bin/passwd*
 

The setuid() and setgid() system calls enable the user and group IDs to be changed. Similarly, the seteuid() and setegid() system calls enable the effective user and effective group ID to be changed:

 
 #include < unistd.h>
 
 int setuid(uid_t uid)
 int seteuid(uid_t euid)
 int setgid(gid_t gid)
 int setegid(gid_t egid)
 

Changing File Times

On occasion it is useful to change the access and modification times. One particular use is in a programming environment where a programmer wishes to force re-compilation of a module. The usual way to achieve this is to run the touchcommand on the file and then recompile. For example:

 $ ls -l hello*
 
 
 -rwxr-xr-x 1 spate fcf 13397 Mar 30 11:53 hello* 
 -rw-r--r-1 spate fcf 31 Mar 30 11:52 hello.c 
 $ make hello 
 
 make: 'hello' is up to date.
 $ touch hello.
 $ ls -l hello.
 -rw-r--r-1 spate fcf 31 Mar 30 11:55 hello.
 $ make hello
 cc hello.c -o hello
 

 
 #include < sys/types.h>
 #include < utime.h>
 
 int utime(const char *filename, struct utimbuf *buf)
 
 #include < sys/time.h>
 
 int utimes(char *filename, struct timeval *tvp)
 
 struct utimbuf {
 time_t actime; /* access time *
 time_t modtime; /* modification time *
 }
 
 struct timeval {
 long tv_sec; /* seconds */ 
 long tv_usec; /* microseconds */ 
 }; 
 

 
 $ strace touch myfile 2>&1 | grep utime
 utime("myfile", NULL) = 
 

 
 $ strace touch -a myfile
 ..
 time([984680824]) = 984680824
 open("myfile"
 O_WRONLY|O_NONBLOCK|O_CREAT|O_NOCTTY|O_LARGEFILE, 0666) = 
 fstat(3, st_mode=S_IFREG|0644, st_size=0, ...) = 
 close(3) = 
 utime("myfile", [2001/03/15-10:27:04, 2001/03/15-10:26:23]) = 
 

Truncating and Removing Files

 
 #include < unistd.h>
 
 int truncate(const char *path, off_t length)
 int ftruncate(int fildes, off_t length)
 


 #include < unistd.h>
 
 int unlink(const char *path)
 

 
 $ touch myfile
 $ ls -l myfile
 -rw-r--r-1 spate fcf 0 Mar 15 11:09 myfile
 $ ln myfile myfile2
 $ ls -l myfile*
 -rw-r--r-2 spate fcf 0 Mar 15 11:09 myfile
 -rw-r--r-2 spate fcf 0 Mar 15 11:09 myfile2
 $ rm myfile
 $ ls -l myfile*
 -rw-r--r-1 spate fcf 0 Mar 15 11:09 myfile2
 $ rm myfile2
 $ ls -l myfile*
 ls: myfile*: No such file or directory
 

Directories

The arguments passed to most directory operations is dependent on where in the file hierarchy the caller is at the time of the call, together with the pathname passed to the command:

Current working directory. This is where the calling process is at the time of the call; it can be obtained through use of pwd from the shell or getcwd() from within a C program.

Absolute pathname. An absolute pathname is one that starts with the character /. Thus to get to the base filename, the full pathname starting at / must be parsed. The pathname /etc/passwd is absolute. Relative pathname. A relative pathname does not contain / as the first character and starts from the current working directory. For example, to reach the same passwd file by specifying passwd the current working directory must be /etc.

 
 Table 2.2 Directory Related Operations 
 
 COMMAND 	SYSTEM CALL 		DESCRIPTION 
 mkdir 		mkdir() 		Make a new directory 
 rmdir 		rmdir() 		Remove a directory 
 pwd 		getcwd() 		Display the current working directory 
 cd			chdir() 		Change directory 
 			fchdir() 
 chroot 		chroot() 		Change the root directory 
 

 
 $ cat dir.
 #include < sys/stat.h>
 #include < sys/types.h>
 #include < sys/param.h>
 #include < fcntl.h>
 #include < unistd.h>
 
 main(
 printf("cwd = %s\n", getcwd(NULL, MAXPATHLEN))
 mkdir("mydir", S_IRWXU)
 chdir("mydir")
 printf("cwd = %s\n", getcwd(NULL, MAXPATHLEN))
 chdir("..")
 rmdir("mydir")
 }
 
 $ make dir
 cc -o dir dir.
 $ ./dir
 cwd = /h/h065/spate/tmp
 cwd = /h/h065/spate/tmp/mydir
 

Special Files

 
 $ ls -l /dev/vx/*dsk/homedg/
 brw------ 1 root root 142,4002 Jun 5 1999 /dev/vx/dsk/homedg/
 crw------ 1 root root 142,4002 Dec 5 21:48 /dev/vx/rdsk/homedg/
 

 
 mknod name b major minor
 mknod name c major minor
 

 
 # mknod /dev/vx/dsk/homedg/h b 142 4002
 # mknod /dev/vx/rdsk/homedg/h c 142 4002
 

 
 #include < sys/stat.h>
 
 int mknod(const char *path, mode_t mode, dev_t dev)
 

 
 S_IFIFO. FIFO special file (named pipe). 
 
 S_IFCHR. Character special file. 
 
 S_IFDIR. Directory file. 
 
 S_IFBLK. Block special file. 
 
 S_IFREG. Regular file.
 

Symbolic Links and Hard Links

 
 #include < unistd.h>
 
 int link(const char *existing, const char *new)
 int symlink(const char *name1, const char *name2)
 

 
 $ echo "Hello world" > myfile
 $ ls -l myfile
 -rw-r--r-1 spate fcf 12 Mar 15 12:17 myfile
 $ cat myfile
 Hello world
 $ strace ln -s myfile mysymlink 2>&1 | grep link
 execve("/bin/ln", ["ln", "-s", "myfile"
 "mysymlink"], [/* 39 vars */]) = 
 lstat("mysymlink", 0xbffff660) = -1 ENOENT (No such file/directory)
 symlink("myfile", "mysymlink") = 
 $ ls -l my*
 -rw-r--r-1 spate fcf 12 Mar 15 12:17 myfile
 lrwxrwxrwx 1 spate fcf 6 Mar 15 12:18 mysymlink -> myfile
 $ cat mysymlink
 Hello world
 $ rm myfile
 $ cat mysymlink
 cat: mysymlink: No such file or directory
 

Named Pipes

 
 $ mkfifo mypipe
 $ ls -l mypipe
 prw-r--r-1 spate fcf 0 Mar 13 11:29 mypipe
 $ echo "Hello world" > mypipe 
 
 [1] 2010
 $ cat < mypipe
 Hello world
 [1]+ Done echo "Hello world" >mypipe
 

 	www.gnu.org/manual/fileutils/html_mono/fileutils.html
 

 	ftp://alpha.gnu.org/gnu/fetish
 

CHAPTER3

User File I/O

To reinforce the material, examples are provided wherever possible. Such examples include simple implementations of various UNIX commands including cat, cp, and dd.

The previous chapter described many of the basic file concepts. This chapter goes one step further and describes the different interfaces that can be called to access files. Most of the APIs described here are at the system call level. Library calls typically map directly to system calls so are not addressed in any detail here.

The material presented here is important for understanding the overall implementation of filesystems in UNIX. By understanding the user-level interfaces that need to be supported, the implementation of filesystems within the kernel is easier to grasp.

Library Functions versus System Calls

Library functions typically provide a richer set of features. For example, the fread() library function reads a number of elements of data of specified size from a file. While presenting this formatted data to the user, internally it will call the read()system call to actually read data from the file.

Library functions are implemented on top of system calls. The decision whether to use system calls or library functions is largely dependent on the application being written. Applications wishing to have much more control over how they perform I/O in order to optimize for performance may well invoke system calls directly. If an application writer wishes to use many of the features that are available at the library level, this could save a fair amount of programming effort. System calls can consume more time than invoking library functions because they involve transferring control of the process from user mode to kernel mode. However, the implementation of different library functions may not meet the needs of the particular application. In other words, whether to use library functions or systems calls is not an obvious choice because it very much depends on the application being written.

Which Header Files to Use?

The header files that are needed are shown in the manual page of the library function or system call to be used. For example, using the stat() system call requires the following two header files:

 #include < sys/types.h>
 #include < sys/stat.h>
 
 int stat(const char path, struct stat buf)
 

Header files that reside in /usr/include are used purely by applications. Those header files that reside in /usr/include/sys are also used by the kernel. Using stat() as an example, a reference to the stat structure is passed from the user process to the kernel, the kernel fills in the fields of the structure and then returns. Thus, in many circumstances, both user processes and the kernel need to understand the same structures and data types.

The Six Basic File Operations

However, before giving its implementation, it is necessary to describe the terms standard input, standard output, and standard error. As described in the section File Descriptors in Chapter 2, the first file that is opened by a user process is assigned a file descriptor value of 3. When the new process is created, it typically inherits the first three file descriptors from its parent. These file descriptors (0, 1, and 2) have a special meaning to routines in the C runtime library and refer to the standard input, standard output, and standard error of the process respectively. When using library routines, a file stream is specified that determines where data is to be read from or written to. Some functions such as printf() write to standard output by default. For other routines such as fprintf(), the file stream must be specified. For standard output, stdout may be used and for standard error, stderrmay be used. Similarly, when using routines that require an input stream, stdin may be used. Chapter 5 describes the implementation of the standard I/O library. For now simply consider them as a layer on top of file descriptors.

When directly invoking system calls, which requires file descriptors, the constants STDIN_FILENO, STDOUT_FILENO, and STDERR_FILENO may be used. These values are defined in unistd.has follows:

 
 #define STDIN_FILENO 0 
 #define STDOUT_FILENO 1 
 #define STDERR_FILENO 2 
 

 
 $ cat # read from standard input
 $ cat file # read from 'file'
 $ cat file > file2 # redirect standard output
 

 
 1 #include < sys/types.h> 
 2 #include < sys/stat.h> 
 3 #include < fcntl.h> 
 4 #include < unistd.h> 
 6 #define BUFSZ 512 
 8 main(int argc, char argv) {
 10 char buf[BUFSZ]; 
 11 int ifd, ofd, nread; 
 13 get_fds(argc, argv, &ifd, &ofd);
 14 while ((nread = read(ifd, buf, BUFSZ)) != 0) 
 15 write(ofd, buf, nread);
 16 }
 17 }
 
 Table 3.1 The Six Basic System Calls Needed for File I/O 
 
 SYSTEM CALL 	FUNCTION 
 open() 			Open an existing file or create a new file 
 creat() 		Create a new file 
 close() 		Close an already open file 
 lseek()			Seek to a specified position in the file 
 read()			Read data from the file from the current position 
 write()			Write data starting at the current position 
 
 

 
 $ mycat
 ifd = STDIN_FILENO
 ofd = STDOUT_FILENO
 
 
 $ mycat file
 ifd = open(file, O_RDONLY)
 ofd = STDOUT_FILENO
 
 
 $ mycat > file
 ifd = STDIN_FILENO
 ofd = open(file, O_WRONLY | O_CREAT)
 
 
 $ mycat fileA > fileB
 ifd = open(fileA, O_RDONLY)
 ofd = open(fileB, O_WRONLY | O_CREAT)
 
 
 The following examples show the program running: 
 
 $ mycat > testfile
 Hello world
 $ mycat testfile
 Hello world
 $ mycat testfile > testfile2
 
 
 
 $ mycat testfile2
 Hello world
 $ mycat
 Hello
 Hello
 world
 world
 

 1. Number all output lines (cat -n). Parse the input strings to detect the -n. 
 2. Print all tabs as ^Iand place a $character at the end of each line (cat -ET). 
 

 
 #include < sys/types.h>
 #include < unistd.h>
 
 off_t lseek(int fildes, off_t offset, int whence)
 

 If whenceis SEEK_SETthe file pointer is set to offsetbytes. 
 If whence is SEEK_CUR the file pointer is set to its current location plus 
 offset. 
 If whence is SEEK_END the file pointer is set to the size of the file plus 
 offset. 
 

By seeking throughout the input and output files, it is possible to see how the dd command can be implemented. As with many UNIX commands, most of the work is done in parsing the command line to determine the input and output files, the starting position to read, the block size for reading, and so on. The example below shows how lseek() is used to seek to a specified starting offset within the input file. In this example, all data read is written to standard output:

 
 1 #include < sys/types.h>
 2 #include < sys/stat.h>
 3 #include < fcntl.h>
 4 #include < unistd.h>
 6 #define BUFSZ 512
 8 main(int argc, char argv)
 9 { 
 10 char *buf; 
 11 int fd, nread; 
 12 off_t offset; 
 13 size_t iosize; 
 15 if (argc != 4) 
 16 printf("usage: mydd filename offset size\n");
 18 fd = open(argv[1], O_RDONLY);
 19 if (fd < 0) 
 20 printf("unable to open file\n");
 21 exit(1);
 22 
 23 offset = (off_t)atol(argv[2]);
 24 buf = (char *)malloc(argv[3]);
 25 lseek(fd, offset, SEEK_SET);
 26 nread = read(fd, buf, iosize);
 27 write(STDOUT_FILENO, buf, nread);
 28 
 

Duplicate File Descriptors

 
 #include < unistd.h>
 
 int dup(int fildes)
 

Seeking and I/O Combined

 
 #include < unistd.h>
 
 ssize_t pread(int fildes, void buf, size_t nbyte, off_t offset)
 ssize_t pwrite(int fildes, const void buf, size_t nbyte,
 
 off_t offset)
 

 1 #include < sys/types.h>
 2 #include < sys/stat.h>
 3 #include < fcntl.h>
 4 #include < unistd.h>
 6 main(int argc, char argv)
 7 { 
 8 char *buf; 
 9 int ifd, ofd, nread; 
 10 off_t inoffset, outoffset; 
 11 size_t insize, outsize; 
 12 
 13 if (argc != 7) { 
 14 printf("usage: mydd infilename in_offset" 
 15 " in_size outfilename out_offset" 
 16 " out_size\n"); 
 17 } 
 18 ifd = open(argv[1], O_RDONLY); 
 19 if (ifd < 0) { 
 20 printf("unable to open %s\n", argv[1]); 
 21 exit(1); 
 22 } 
 23 ofd = open(argv[4], O_WRONLY); 
 24 if (ofd < 0) { 
 25 printf("unable to open %s\n", argv[4]); 
 26 exit(1); 
 27 } 
 28 inoffset = (off_t)atol(argv[2]); 
 29 insize = (size_t)atol(argv[3])
 30 outoffset = (off_t)atol(argv[5])
 31 outsize = (size_t)atol(argv[6])
 32 buf = (char *)malloc(insize)
 33 if (insize < outsize)
 34 outsize = insize;
 35
 36 nread = pread(ifd, buf, insize, inoffset)
 37 pwrite(ofd, buf,
 38 (nread < outsize) ? nread : outsize, outoffset)
 39 
 

 
 $ cat fileA
 0123456789
 $ cat fileB
 
 
 $ mydd2 fileA 2 4 fileB 4 
 $ cat fileA
 0123456789
 $ cat fileB
 ----234-
 

For the pread()/pwrite() combination the average time to complete the I/O loop was 25 seconds while for the lseek()/read() and lseek()/write() combinations the average time was 35 seconds, which shows a considerable difference.

This test shows the advantage of pread() and pwrite() in its best form. In general though, if an lseek() is immediately followed by a read() or write(), the two calls should be combined.

Data and Attribute Caching

Firstly, there are three options, supported under the Single UNIX Specification, that can be passed to open() that have an impact on subsequent I/O operations. When a write takes place, there are two items of data that must be written to disk, namely the file data and the files inode. An inode is the object stored on disk that describes the file, including the properties seen by calling stat() together with a block map of all data blocks associated with the file.

The three options that are supported from a standards perspective are:

 1. O_SYNC.For all types of writes, whether allocation is required or not, the data and any meta-data updates are committed to disk before the write returns. For reads, the access time stamp will be updated before the read returns.

2. O_DSYNC. When a write occurs, the data will be committed to disk before the write returns but the files meta-data may not be written to disk at this stage. This will result in better I/O throughput because, if implemented efficiently by the filesystem, the number of inode updates will be minimized, effectively halving the number of writes. Typically, if the write results in an allocation to the file (a write over a hole or beyond the end of the file) the meta-data is also written to disk. However, if the write does not involve an allocation, the timestamps will typically not be written synchronously.

3. O_RSYNC. If both the O_RSYNC and O_DSYNC flags are set, the read returns after the data has been read and the file attributes have been updated on disk, with the exception of file timestamps that may be written later. If there are any writes pending that cover the range of data to be read, these writes are committed before the read returns.

If both the O_RSYNC and O_SYNC flags are set, the behavior is identical to that of setting O_RSYNC and O_DSYNC except that all file attributes changed by the read operation (including all time attributes) must also be committed to disk before the read returns. Which option to choose is dependent on the application. For I/O intensive applications where timestamps updates are not particularly important, there can be a significant performance boost by using O_DSYNCin place of O_SYNC.

VxFS Caching Advisories

The following example shows the effect that selecting O_SYNC versus O_DSYNC can have on an application:

 #include < sys/unistd.h>
 #include < sys/types.h>
 #include < fcntl.h>
 
 main(int argc, char argv[]{
 
 char buf[4096]
 int i, fd, advisory;
 
 fd = open("myfile", O_WRONLY|O_DSYNC)
 for (i=0 ; i<1024 ; i++) 
 write(fd, buf, 4096)
 

 
 # time ./sync
 real 0m8.33s
 user 0m0.03s
 sys 0m1.92s
 # time ./dsync
 real 0m6.44s
 user 0m0.02s
 sys 0m0.69s
 

Before showing how these caching advisories can be used it is first necessary to describe how to use the ioctl() system call. The definition of ioctl(), which is not part of any UNIX standard, differs slightly from platform to platform by requiring different header files. The basic definition is as follows:

 #include < unistd.h> # Solaris
 #include < stropts.h> # Solaris, AIX and HP-UX
 #include < sys/ioctl.h> # Linux
 
 int ioctl(int fildes, int request, /* arg ... */)
 

The following program shows how the caching advisories are used in practice. The program takes VX_SEQ, VX_RANDOM, or VX_DIRECT as an argument and reads a 1MB file in 4096 byte chunks.

 #include < sys/unistd.h>
 #include < sys/types.h>
 #include < fcntl.h>
 #include "sys/fs/vx_ioctl.h"
 
 #define MB (1024 * 1024)
 
 main(int argc, char argv[]
 { 
 char *buf; 
 int i, fd, advisory; 
 long pagesize, pagemask;
  if (argc != 2) exit(1);
 if (strcmp(argv[1], "VX_SEQ") == 0) 
 {
 	advisory = VX_SEQ; 
 } else if (strcmp(argv[1], "VX_RANDOM") == 0) 
 {
 advisory = VX_RANDOM; 
 } else if (strcmp(argv[1], "VX_DIRECT") == 0) 
 
 advisory = VX_DIRECT; 
 pagesize = sysconf(_SC_PAGESIZE)
 pagemask = pagesize - 1; 
 buf = (char *)(malloc(2 * pagesize) & pagemask)
 buf = (char *)(((long)buf + pagesize) & ~pagemask)
 
 
 fd = open("myfile", O_RDWR)
 ioctl(fd, VX_SETCACHE, advisory)
 for (i=0 ; i< MB ; i++) {
 read(fd, buf, 4096)
 }
 }
 

 
 VX_SEQ
 
 real 2:47.6
 user 5.9
 sys 2:41.4
 
 VX_DIRECT
 
 real 2:35.7
 user 6.7
 sys 2:28.7
 
 VX_RANDOM
 
 real 2:43.6
 user 5.2
 sys 2:38.1
 

Miscellaneous Open Options

File and Record Locking

There are numerous uses for file locking. However, looking at database file access gives an excellent example of the types of locks that applications require. For example, it is important that all users wishing to view database records are able to do so simultaneously. When updating records it is imperative that while one record is being updated, other users are still able to access other records. Finally it is imperative that records are updated in a time-ordered manner.

There are two types of locks that can be used to coordinate access to files, namely mandatory and advisory locks. With advisory locking, it is possible for cooperating processes to safely access a file in a controlled manner. Mandatory locking is somewhat of a hack and will be described later. The majority of this section will concentrate on advisory locking, sometimes called record locking.

Advisory Locking

 
 /usr/ucb/cc [ flag ... ] file ..
 #include < sys/file.h>
 
 int flock(fd, operation)
 int fd, operation;
 

The lockf() function, which is typically implemented as a call to fcntl(), can be invoked to apply or remove an advisory lock on a segment of a file as follows:

 #include < sys/file.h>
 
 int lockf(int fildes, int function, off_t size)
 

The functionargument can be one of the following:
F_LOCK. This command sets an exclusive lock on the file. If the file is already locked, the calling process will block until the previous lock is relinquished.
F_TLOCK. This performs the same function as the F_LOCK command but will not blockthus if the file is already locked, EAGAIN is returned.
F_ULOCK. This command unlocks a segment of the file.
F_TEST. This command is used to test whether a lock exists for the specified segment. If there is no lock for the segment, 0 is returned, otherwise -1 is returned, and errno is set to EACCES.

If the segment to be locked contains a previous locked segment, in whole or part, the result will be a new, single locked segment. Similarly, if F_ULOCKis specified, the segment of the file to be unlocked may be a subset of a previously locked segment or may cover more than one previously locked segment. If size is 0, the file is unlocked from the current file offset to the end of the file. If the segment to be unlocked is a subset of a previously locked segment, the result will be one or two smaller locked segments.

It is possible to reach deadlock if two processes make a request to lock segments of a file owned by each other. The kernel is able to detect this and, if the condition would occur, EDEADLK is returned.

Note as mentioned above that flock()is typically implemented on top of the fcntl() system call, for which there are three commands that can be passed to manage record locking. Recall the interface for fcntl():

 #include < sys/types.h>
 #include < unistd.h>
 #include < fcntl.h>
 
 int fcntl(int fildes, int cmd, ...)
 

 struct flock {
 	short l_type; /* F_RDLCK, F_WRLCK or F_UNLOCK */ 
 	short l_whence; /* flag for starting offset */ 
 	off_t l_start; /* relative offset in bytes */ 
 	off_t l_len; /* size; if 0 then until EOF */ 
 	pid_t l_pid; /* process ID of lock holder */ 
 }; 
 

Because record locking as defined by fcntl() is supported by all appropriate UNIX standards, this is the routine that should be ideally used for application portability.

The following code fragments show how advisory locking works in practice. The first program, lock, which follows, sets a writable lock on the whole of the file myfile and calls pause() to wait for a SIGUSR1 signal. After the signal arrives, a call is made to unlock the file.


 1 #include < sys/types.h> 
 2 #include < unistd.h> 
 3 #include < fcntl.h> 
 4 #include < signal.h>
 
 6 void 
 7 mysig(int signo)
 8 { 
 9 return; 
 10 } 
 11 
 12 main() 
 13 { 
 14 struct flock lk; 
 15 int fd, err; 
 16 
 17 sigset(SIGUSR1, mysig);
 18
 19 fd = open("myfile", O_WRONLY)
 20
 21 lk.l_type = F_WRLCK;
 22 lk.l_whence = SEEK_SET;
 23 lk.l_start = 0;
 24 lk.l_len = 0;
 25 lk.l_pid = getpid()
 26
 27 err = fcntl(fd, F_SETLK, &lk)
 28 printf("lock: File is locked\n")
 29 pause()
 30 lk.l_type = F_UNLCK;
 31 err = fcntl(fd, F_SETLK, &lk)
 32 printf("lock: File is unlocked\n")
 33 }
 

The next program (mycatl) is a modified version of the cat program that will only display the file if there are no write locks held on the file. If a lock is detected, the program loops up to 5 times waiting for the lock to be released. Because the lock will still be held by the lock program, mycatl will extract the process ID from the flock structure returned by fcntl() and post a SIGUSR1 signal. This is handled by the lock program which then unlocks the file.

 1 #include < sys/types.h> 
 2 #include < sys/stat.h> 
 3 #include < fcntl.h> 
 4 #include < unistd.h> 
 5 #include < signal.h> 
 7 pid_
 8 is_locked(int fd) 
 9 {
 10 struct flock lk; 
 11 
 12 lk.l_type = F_RDLCK; 
 13 lk.l_whence = SEEK_SET; 
 14 lk.l_start = 0; 
 15 lk.l_len = 0; 
 16 lk.l_pid = 0; 
 17 
 18 fcntl(fd, F_GETLK, &lk); 
 19 return (lk.l_type == F_UNLCK) ? 0 : lk.l_pid; 
 20 } 
 21 
 22 main() 
 23 { 
 24 struct flock lk; 
 25 int i, fd, err; 
 26 pid_t pid; 
 27 
 28 fd = open("myfile", O_RDONLY); 
 29 
 30 for (i = 0 ; i < 5 ; i++) { 
 31 if ((pid = is_locked(fd)) == 0) { 
 32 catfile(fd); 
 33 exit(0); 
 34 } else { 
 35 printf("mycatl: File is locked ...\n"); 
 36 sleep(1); 
 37 } 
 38 } 
 
 39 kill(pid, SIGUSR1)
 40 while ((pid = is_locked(fd)) != 0) {
 41 printf("mycatl: Waiting for lock release\n")
 42 sleep(1)
 43 }
 44 catfile(fd)
 45 }
 

 
 $ cat myfile
 Hello world
 $ lock&
 
 [1] 2448
 lock: File is locked
 $ mycatl
 mycatl: File is locked ..
 mycatl: File is locked ..
 mycatl: File is locked ..
 mycatl: File is locked ..
 mycatl: File is locked ..
 mycatl: Waiting for lock release
 
 
 
 lock: File is unlocked
 Hello world
 [1]+ Exit 23 ./lock
 

 $ lock&
 
 [1] 2494
 lock: File is locked
 $ cat myfile
 Hello world
 $ rm myfile
 $ jobs
 [1]+ Running ./lock 
 

Mandatory Locking

Mandatory locking can be enabled on a file if the set group ID bit is switched on and the group execute bit is switched offa combination that together does not otherwise make any sense. Thus if the following were executed on a system that supports mandatory locking:

 $ lock&
 [1] 12096
 lock: File is locked
 $ cat myfile # The cat program blocks here
 

File Control Operations

 #include < sys/types.h>
 #include < unistd.h>
 #include < fcntl.h>
 
 int fcntl(int fildes, int cmd, ...)
 

Vectored Reads and Writes

Here are the definitions for both functions:

 #include < sys/uio.h>
 
 ssize_t readv(int fildes, const struct iovec iov, int iovcnt)
 ssize_t writev(int fildes, const struct iovec iov, int iovcnt)
 

 struct uio {
  void *iov_base; /* Address in memory of buffer for r/w *
  size_t iov_len; /* Size of the above buffer in memory *
 }
 

The following program corresponds to the example shown in Figure 3.1:

 1 #include < sys/uio.h>
 2 #include < unistd.h>
 3 #include < fcntl.h>
 4 
 5 main() 
 6 { 
 7 struct iovec uiop[3]; 
 8 void *addr1, *addr2, *addr3; 
 9 int fd, nbytes; 
 10 
 11 addr1 = (void *)malloc(4096)
 12 addr2 = (void *)malloc(4096)
 13 addr3 = (void *)malloc(4096)
 14
 15 uiop[0].iov_base = addr1; uiop[0].iov_len = 512;
 16 uiop[1].iov_base = addr2; uiop[1].iov_len = 512;
 17 uiop[2].iov_base = addr3; uiop[2].iov_len = 1024;
 18
 19 fd = open("myfile", O_RDONLY)
 20 nbytes = readv(fd, uiop, 3)
 21 printf("number of bytes read = %d\n", nbytes)
 22 
 

 $ readv
 number of bytes read = 2048
 

Asynchronous I/O

As an example of where async I/O is commonly used, consider the Oracle database writer process (DBWR), one of the main Oracle processes; its role is to manage the Oracle buffer cache, a user-level cache of database blocks. This involves responding to read requests and writing dirty (modified) buffers to disk.

In an active database, the work of DBWR is complicated by the fact that it is constantly writing dirty buffers to disk in order to allow new blocks to be read. Oracle employs two methods to help alleviate some of the performance bottlenecks. First, it supports multiple DBWR processes (called DBWR slave processes); the second option, which greatly improves throughput, is through use of async I/O. If I/O operations are being performed asynchronously, the DBWR processes can be doing other work, whether flushing more buffers to disk, reading data from disk, or other internal functions.

All of the Single UNIX Specification async I/O operations center around an I/O control block defined by the aiocbstructure as follows:


 struct aiocb { 
 int aio_fildes; /* file descriptor */ 
 off_t aio_offset; /* file offset */ 
 volatile void *aio_buf; /* location of buffer */ 
 size_t aio_nbytes; /* length of transfer */ 
 int aio_reqprio; /* request priority offset */ 
 struct sigevent aio_sigevent; /* signal number and value */ 
 int aio_lio_opcode; /* operation to be performed */ 
 }; 
 

 cc [ flag... ] file... -lrt [ library... 
 #include < aio.h>
 int aio_read(struct aiocb aiocbp)
 

Similarly, to perform an asynchronous write operation, the function to call is aio_write()which is defined as follows:

 cc [ flag... ] file... -lrt [ library... 
 #include < aio.h>
 
 int aio_write(struct aiocb aiocbp)
 

In order to retrieve the status of a pending I/O, there are two interfaces that can be used. One involves the posting of a signal and will be described later; the other involves the use of the aio_return() function as follows:

 #include < aio.h>
 
 ssize_t aio_return(struct aiocb aiocbp)
 

The following example shows some interesting properties of an asynchronous write:

 1 #include < aio.h>
 2 #include < time.h>
 3 #include < errno.h>
 4 
 5 #define FILESZ (1024 * 1024 * 64) 
 6 
 7 main() 
 8 { 
 9 struct aiocb aio; 
 10 void *buf; 
 11 time_t time1, time2; 
 12 int err, cnt = 0; 
 13 
 
 14 buf = (void *)malloc(FILESZ)
 15 aio.aio_fildes = open("/dev/vx/rdsk/fs1", O_WRONLY)
 16 aio.aio_buf = buf;
 17 aio.aio_offset = 0;
 18 aio.aio_nbytes = FILESZ;
 19 aio.aio_reqprio = 0;
 20
 21 time(&time1)
 22 err = aio_write(&aio)
 23 while ((err = aio_error(&aio)) == EINPROGRESS) {
 24 sleep(1)
 25 }
 26 time(&time2)
 27 printf("The I/O took %d seconds\n", time2 - time1)
 28 }
 

 
 cc [ flag... ] file... -lrt [ library... 
 #include 
 int aio_error(const struct aiocb aiocbp)
 

 # aiowrite
 The I/O took 7 seconds
 

For async I/O operations that are still pending, the aio_cancel() function can be used to cancel the operation:

 cc [ flag... ] file... -lrt [ library... 
 #include < aio.h>
 
 int aio_cancel(int fildes, struct aiocb aiocbp)
 

As an example, following the above call to aio_write(), this code is inserted:

 err = aio_cancel(aio.aio_fildes, &aio)
 
 switch (err) {
 
  case AIO_CANCELED:
 	errstr = "AIO_CANCELED"
 	 break;
 case AIO_NOTCANCELED:
 	 errstr = "AIO_NOTCANCELED"
 	 break;
 case AIO_ALLDONE:
 	 errstr = "AIO_ALLDONE"
 	 break;
 default:
  errstr = "Call failed"
 }
 printf("Error value returned %s\n", errstr)
 

 	Error value returned AIO_CANCELED
 

 	Error value returned AIO_NOTCANCELED
 

As mentioned above, the Oracle DBWR process will likely issue multiple I/Os simultaneously and wait for them to complete at a later time. Multiple read() and write() system calls can be combined through the use of readv() and write() to help cut down on system call overhead. For async I/O, the lio_listio()function achieves the same result:

 #include < aio.h>
 
 int lio_listio(int mode, struct aiocb const list[], int nent, 
 struct sigevent sig)
 

If the mode flag is LIO_NOWAIT, the sig argument specifies the signal that should be posted to the process once the I/O has completed.

The following example uses lio_listio() to issue two async writes to different parts of the file. Once the I/O has completed, the signal handler aiohdlr() will be invoked; this displays the time that it took for both writes to complete.

 1 #include < aio.h> 
 2 #include < time.h> 
 3 #include < errno.h> 
 4 #include < signal.h> 
 6 #define FILESZ (1024 * 1024 * 64) 
 7 time_t time1, time2; 
 9 void
 10 aiohdlr(int signo)
 11 {
 12 time(&time2)
 13 printf("Time for write was %d seconds\n", time2 - time1)
 14 } 
 15 
 16 main() 
 17 { 
 18 struct sigevent mysig; 
 19 struct aiocb *laio[2]; 
 20 struct aiocb aio1, aio2; 
 21 void *buf; 
 22 char errstr; 
 23 int fd; 
 24 
 25 buf = (void *)malloc(FILESZ)
 26 fd = open("/dev/vx/rdsk/fs1", O_WRONLY)
 27
 28 aio1.aio_fildes = fd;
 29 aio1.aio_lio_opcode = LIO_WRITE;
 30 aio1.aio_buf = buf;
 31 aio1.aio_offset = 0;
 32 aio1.aio_nbytes = FILESZ;
 33 aio1.aio_reqprio = 0;
 34 laio[0] = &aio1;
 35
 36 aio2.aio_fildes = fd;
 37 aio2.aio_lio_opcode = LIO_WRITE;
 38 aio2.aio_buf = buf;
 39 aio2.aio_offset = FILESZ;
 40 aio2.aio_nbytes = FILESZ;
 41 aio2.aio_reqprio = 0;
 42 laio[1] = &aio2;
 43
 44 sigset(SIGUSR1, aiohdlr)
 45 mysig.sigev_signo = SIGUSR1;
 46 mysig.sigev_notify = SIGEV_SIGNAL;
 47 mysig.sigev_value.sival_ptr = (void *)laio;
 48
 49 time(&time1)
 50 lio_listio(LIO_NOWAIT, laio, 2, &mysig)
 51 pause()
 52 }
 

When the program is run the following is observed:

 # listio
 Time for write was 12 seconds
 

Memory Mapped Files

The mmap() system call allows a process to establish a mapping to an already open file:

 #include < sys/mman.h>
 
 void mmap(void addr, size_t len, int prot, int flags,
 int fildes, off_t off)
 

Figure 3.2 shows the relationship between the pages in the users address space and how they relate to the file being mapped. The page size of the underlying hardware platform can be determined by making a call to sysconf()as follows:

 #include < unistd.h>
 main(){
  printf("PAGESIZE = %d\n", sysconf(_SC_PAGESIZE))
 }
 

 # ./sysconf
 PAGESIZE = 4096
 

 # ./sysconf
 PAGESIZE = 8192
 

Note that after the file has been mapped it can be closed and still accessed through the mapping.

Before describing the other parameters, here is a very simple example showing the basics of mmap(): 1 #include < sys/types.h> 2 #include < sys/stat.h> 3 #include < sys/mman.h> 4 #include < fcntl.h> 5 #include < unistd.h> 7 #define MAPSZ 4096 9 main() 10 { 11 char *addr, c; 12 int fd; 13 14 fd = open("/etc/passwd", O_RDONLY) 15 addr = (char *)mmap(NULL, MAPSZ, 16 PROT_READ, MAP_SHARED, fd, 0) 17 close(fd) 18 for (;;) { 19 c = *addr; 20 putchar(c) 21 addr++ 22 if (c == \n) { 23 exit(0) 24 } 25 } 26 } The /etc/passwd file is opened and a call to mmap() is made to map the first MAPSZ bytes of the file. A file offset of 0 is passed. The PROT_READ and MAP_SHAREDarguments describe the type of mapping and how it relates to other processes that map the same file. The prot argument (in this case PROT_READ) can be one of the following:
PROT_READ. The data can be read.
PROT_WRITE. The data can be written.
PROT_EXEC. The data can be executed.
PROT_NONE. The data cannot be accessed.

Note that the different access types can be combined. For example, to specify read and write access a combination of (PROT_READ|PROT_WRITE) may be specified. By specifying PROT_EXEC it is possible for application writers to produce their own dynamic library mechanisms. The PROT_NONE argument can be used for user level memory management by preventing access to certain parts of memory at certain times. Note that PROT_NONE cannot be used in conjunction with any other flags.

The flagsargument can be one of the following:
MAP_SHARED. Any changes made through the mapping will be reflected back to the mapped file and are visible by other processes calling mmap() and specifying MAP_SHARED.
MAP_PRIVATE. Any changes made through the mapping are private to this process and are not reflected back to the file.
MAP_FIXED. The addr argument should be interpreted exactly. This argument will be typically used by dynamic linkers to ensure that program text and data are laid out in the same place in memory for each process. If MAP_FIXED is specified and the area specified in the mapping covers an already existing mapping, the initial mapping is first unmapped.

Note that in some versions of UNIX, the flags have been enhanced to include operations that are not covered by the Single UNIX Specification. For example, on the Solaris operating system, the MAP_NORESERVE flag indicates that swap space should not be reserved. This avoids unnecessary wastage of virtual memory and is especially useful when mappings are read-only. Note, however, that this flag is not portable to other versions of UNIX.

To give a more concrete example of the use of mmap(), an abbreviated implementation of the cp utility is given. This is how some versions of UNIX actually implement cp.

 1 #include < sys/types.h> 
 2 #include < sys/stat.h> 
 3 #include < sys/mman.h> 
 4 #include < fcntl.h> 
 5 #include < unistd.h> 
 7 #define MAPSZ 4096 
 9 main(int argc, char argv)
 10 { 
 11 struct stat st; 
 12 size_t iosz; 
 13 off_t off = 0; 
 14 void *addr; 
 15 int ifd, ofd; 
 16 
 17 if (argc != 3) { 
 18 
 printf("Usage: mycp srcfile destfile\n")
 19 exit(1)
 20 }
 21 if ((ifd = open(argv[1], O_RDONLY)) < 0) 
 22 printf("Failed to open %s\n", argv[1])
 23 
 24 if ((ofd = open(argv[2], 
 25 O_WRONLY|O_CREAT|O_TRUNC, 0777)) < 0) { 
 26 printf("Failed to open %s\n", argv[2]); 
 27 } 
 28 fstat(ifd, &st); 
 29 if (st.st_size < MAPSZ) { 
 30 addr = mmap(NULL, st.st_size, 
 31 PROT_READ, MAP_SHARED, ifd, 0); 
 32 printf("Mapping entire file\n"); 
 33 close(ifd); 
 34 write (ofd, (char *)addr, st.st_size); 
 35 } else { 
 36 printf("Mapping file by MAPSZ chunks\n"); 
 37 while (off <= st.st_size) { 
 38 addr = mmap(NULL, MAPSZ, PROT_READ, 
 39 MAP_SHARED, ifd, off); 
 40 if (MAPSZ < (st.st_size - off)) { 
 41 iosz = MAPSZ; 
 42 } else { 
 43 iosz = st.st_size - off; 
 44 } 
 45 write (ofd, (char *)addr, iosz); 
 46 off += MAPSZ; 
 47 } 
 48 } 
 49 } 
 

If the attempt at mapping the whole file fails, the program loops (lines 37-47) mapping sections of the file and writing them to the file to be copied.

Note that in the example here, MAP_PRIVATE could be used in place of MAP_SHARED since the file was only being read. Here is an example of the program running:

 $ cp mycp.c fileA
 $ mycp fileA fileB
 Mapping entire file
 $ diff fileA fileB
 $ cp mycp fileA
 $ mycp fileA fileB
 Mapping file by MAPSZ chunks
 $ diff fileA fileB
 

 $ dd if=/dev/zero of=20kfile bs=4096 count=
 5+0 records in
 5+0 records out
 $ mycp_profile 20kfile newfile
 Mapping file by MAPSZ chunks
 map addr = 0x40019000
 map addr = 0x4001a000
 map addr = 0x4001b000
 map addr = 0x4001c000
 map addr = 0x4001d000
 map addr = 0x4001e000
 

 
 #include < sys/mman.h>
 int munmap(void *addr, size_t len)
 

 	munmap(addr, iosz)
 

 $ mycp2 20kfile newfile
 Mapping file by MAPSZ chunks
 map addr = 0x40019000
 map addr = 0x40019000
 map addr = 0x40019000
 map addr = 0x40019000
 map addr = 0x40019000
 map addr = 0x40019000
 

After a mapping is established with a specific set of access protections, it may be desirable to change these protections over time. The mprotect() system call allows the protections to be changed:

 #include < sys/mman.h>
 
 	int mprotect(void *addr, size_t len, int prot)
 

The other system call that is of importance with respect to memory mapped files is msync(), which allows modifications to the mapping to be flushed to the underlying file:

 #include < sys/mman.h>
 
 int msync(void *addr, size_t len, int flags)
 

Thus, a call to mmap() followed by modification of the data followed by a call to msync() specifying the MS_SYNC flag is similar to a call to write() following a call to open() and specifying the O_SYNCflag. By specifying the MS_ASYNCflag, this is loosely synonymous to opening a file without the O_SYNC flag. However, calling msync() with the MS_ASYNCflag is likely to initiate the I/O while writing to a file without specifying O_SYNC or O_DSYNCcould result in data sitting in the system page or buffer cache for some time.

One unusual property of mapped files occurs when the pseudo device /dev/zerois mapped. As one would expect, this gives access to a contiguous set of zeroes covering any part of the mapping that is accessed. However, following a mapping of /dev/zero, if the process was to fork, the mapping would be visible by parent and child. If MAP_PRIVATEwas specified on the call to mmap(), parent and child will share the same physical pages of the mapping until a modification is made at which time the kernel will copy the page that makes the modification private to the process which issued the write.

If MAP_SHARED is specified, both parent and children will share the same physical pages regardless of whether read or write operations are performed.

64-Bit File Access (LFS)

In order to provide both an explicit means of accessing large files as well as a hidden and easily upgradable approach, there were two programmatic models. The first allowed the size of off_t to be determined during the compilation and linking process. This effectively sets the size of off_t and determines whether the standard system calls such as read() and write() will be used or whether the large file specific libraries will be used. Either way, the application continues to use read(), write(), and related system calls, and the mapping is done during the link time.

The second approach provided an explicit model whereby the size of off_t was chosen explicitly within the program. For example, on a 32-bit OS, the size of off_t would be 32 bits, and large files would need to be accessed through use of the off64_t data type. In addition, specific calls such as open64(), read64()would be required in order to access large files.

Today, the issue has largely gone away, with most operating systems supporting large files by default.

Sparse Files

A sparse file is simply a file that contains one or more holes. This statement itself is probably the reason for the confusion. A hole is a gap within the file for which there are no allocated data blocks. For example, a file could contain a 1KB data block followed by a 1KB hole followed by another 1KB data block. The size of the file would be 3KB but there are only two blocks allocated. When reading over a hole, zeroes will be returned.

The following example shows how this works in practice. First of all, a 20MB filesystem is created and mounted:

 # mkfs -F vxfs /dev/vx/rdsk/rootdg/vol2 20m
 version 4 layout
 40960 sectors, 20480 blocks of size 1024, log size 1024 blocks
 unlimited inodes, largefiles not supported
 20480 data blocks, 19384 free data blocks
 1 allocation units of 32768 blocks, 32768 data blocks
 last allocation unit has 20480 data blocks
 # mount -F vxfs /dev/vx/dsk/rootdg/vol2 /mnt2
 

 #include < sys/types.h>
 #include < fcntl.h>
 #include < unistd.h>
 
 #define IOSZ (1024 * 1024 *64)
 
 main() {
 
  int fd;
  fd = open("/mnt2/newfile", O_CREAT | O_WRONLY, 0666)
  lseek(fd, IOSZ, SEEK_SET)
  write(fd, "a", 1)
 }
 

 # ./lf
 # ls -l /mnt2
 total 
 drwxr-xr-x 2 root root 96 Jun 13 08:25 lost+found/
 -rw-r--r 1 root other 67108865 Jun 13 08:28 newfile
 # df -k | grep mnt2
 /dev/vx/dsk/rootdg/vol2 20480 1110 18167 6% /mnt2
 

To help understand how sparse files can be useful, consider how storage is allocated to a file in a hypothetical filesystem. For this example, consider a filesystem that allocates storage to files in 1KB chunks and consider the interaction between the user and the filesystem as follows:

In this example, following the close()call, the file has a size of 2048 bytes. The data written to the file is stored in two 1k blocks. Now, consider the example below:

 User				 Filesystem 
 create() 			Create a new file 
 write(1k of as) 	Allocate a new 1k block for range 0 to 1023 bytes 
 write(1k of bs) 	Allocate a new 1k block for range 1024 to 2047 bytes 
 close() 			Close the file 
 

Note that although filesystems will differ in their individual implementations, each file will contain a block map mapping the blocks that are allocated to the file and at which offsets. Thus, in Figure 3.3, the hole is explicitly marked.

So what use are sparse files and what happens if the file is read? All UNIX standards dictate that if a file contains a hole and data is read from a portion of a file containing a hole, zeroes must be returned. Thus when reading the sparse file above, we will see the same result as for a file created as follows:

 User 				Filesystem 
 create() 			Create a new file 
 write(1k of 0s) 	Allocate a new 1k block for range 1023 to 2047 bytes 
 write(1k of bs) 	Allocate a new 1k block for range 1024 to 2047 bytes 
 close()				Close the file 
 

The following program shows the example described above:

 1 #include < sys/types.h> 
 2 #include < fcntl.h> 
 3 #include < unistd.h>
 5 main() 
 6 { 
 7 char buf[1024]; 
 8 int fd; 
 9 
 10 memset(buf, a, 1024); 
 11 fd = open("newfile", O_RDWR|O_CREAT|O_TRUNC, 0777); 
 12 lseek(fd, 1024, SEEK_SET); 
 13 write(fd, buf, 1024); 
 14 } 
 

 $ od -c newfile
 0000000 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \
 0002000 a a a a a a a a a a a a a a a 
 0004000
 

 memset(buf, 'b', 512)
 fd = open("newfile", O_RDWR)
 lseek(fd, 256, SEEK_SET)
 write(fd, buf, 512)
 

 $ od -c newfile
 0000000 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \
 0000400 b b b b b b b b b b b b b b b 
 0001400 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \
 0002000 a a a a a a a a a a a a a a a 
 0004000
 

 #include < sys/types.h>
 #include < fcntl.h>
 #include < unistd.h>
 
 main()
 {
 int fd; 
 char buf[1024]
 fd = open("myfile", O_CREAT | O_WRONLY, 0666)
 lseek(fd, 8192, SEEK_SET)
 write(fd, buf, 1024)
 }
 

 # ./sparse
 # ls -l myfile
 -rw-r--r 1 root other 9216 Jun 13 08:37 myfile
 # ls -i myfile
 6 myfile
 

 # umount /mnt2
 # fsdb -F vxfs /dev/vx/rdsk/rootdg/vol2
 # > 6i
 inode structure at 0x00000431.0200
 type IFREG mode 100644 nlink 1 uid 0 gid 1 size 9216
 atime 992447379 122128 (Wed Jun 13 08:49:39 2001)
 mtime 992447379 132127 (Wed Jun 13 08:49:39 2001)
 ctime 992447379 132127 (Wed Jun 13 08:49:39 2001)
 aflags 0 orgtype 1 eopflags 0 eopdata 
 fixextsize/fsindex 0 rdev/reserve/dotdot/matchino 
 blocks 1 gen 844791719 version 0 13 iattrino 
 de: 0 1096 0 0 0 0 0 0 0 
 des: 8 1 0 0 0 0 0 0 0 
 ie: 0 
 ies: 
 

Summary

This chapter provided an introduction to file I/O based system calls. It is important to grasp these concepts before trying to understand how filesystems are implemented. By understanding what the user expects, it is easier to see how certain features are implemented and what the kernel and individual filesystems are trying to achieve.

Whenever programming on UNIX, it is always a good idea to follow appropriate standards to allow programs to be portable across multiple versions of UNIX. The commercial versions of UNIX typically support the Single UNIX Specification standard although this is not fully adopted in Linux and BSD. At the very least, all versions of UNIX will support the POSIX.1 standard.

CHAPTER4

The Standard I/O Library

There are many books that describe the calls provided by the standard I/O library (stdio). This chapter offers a different approach by describing the implementation of the Linux standard I/O library showing the main structures, how they support the functions available, and how the library calls map onto the system call layer of UNIX.

The needs of the application will dictate whether the standard I/O library will be used as opposed to basic file-based system calls. If extra functionality is required and performance is not paramount, the standard I/O library, with its rich set of functions, will typically meet the needs of most programmers. If performance is key and more control is required over the execution of I/O, understanding how the filesystem performs I/O and bypassing the standard I/O library is typically a better choice.

Rather than describing the myriad of stdio functions available, which are well documented elsewhere, this chapter provides an overview of how the standard I/O library is implemented. For further details on the interfaces available, see Richard Stevens book Advanced Programming in the UNIX Programming Environment [STEV92] or consult the Single UNIX Specification.

The FILE Structure

 struct _IO_FILE 
 {
 	char *_IO_read_ptr; /* Current read pointer */ 
 	char *_IO_read_end; /* End of get area. */ 
 	char *_IO_read_base; /* Start of putback and get area. */ 
 	char *_IO_write_base; /* Start of put area. */ 
 	char *_IO_write_ptr; /* Current put pointer. */ 
 	char *_IO_write_end; /* End of put area. */ 
 	char *_IO_buf_base; /* Start of reserve area. */ 
 	char *_IO_buf_end; /* End of reserve area. */ 
 	int _fileno; 
 	int _blksize; 
 }; 
 
 typedef struct _IO_FILE FILE;
 

 fd = open("/etc/passwd", O_RDONLY)
 read(fd, buf, 1024)
 

Standard Input, Output, and Error


 extern FILE *stdin;
 extern FILE *stdout;
 extern FILE *stderr;
 

There are some standard I/O library routines that operate on the standard input and output streams explicitly. For example, a call to printf() uses stdin by default whereas a call to fprintf() requires the caller to specify a file stream. Similarly, a call to getchar() operates on stdin while a call to getc() requires the file stream to be passed. The declaration of getchar()could simply be:

 #define getchar() getc(stdin)
 

Opening and Closing a Stream

 #include < stdio.h>
 
 FILE *fopen(const char *filename, const char *mode)
 int fclose(FILE *stream)
 

Internally, the standard I/O library will map these flags onto the corresponding flags to be passed to the open() system call. For example, r will map to O_RDONLY, r+ will map to O_RDWR and so on. The process followed when opening a stream is shown in Figure 4.1.

The following example shows the effects of some of the library routines on the FILE structure:

 1 #include < stdio.h>
 2 
 3 main() 
 4 { 
 5 FILE *fp1, *fp2; 
 6 char c; 
 7 
 8 fp1 = fopen("/etc/passwd", "r")
 9 fp2 = fopen("/etc/mtab", "r")
 10 printf("address of fp1 = 0x%x\n", fp1)
 11 printf(" fp1->_fileno = 0x%x\n", fp1->_fileno)
 12 printf("address of fp2 = 0x%x\n", fp2)
 13 printf(" fp2->_fileno = 0x%x\n\n", fp2->_fileno)
 14
 15 c = getc(fp1)
 16 c = getc(fp2)
 17 printf(" fp1->_IO_buf_base = 0x%x\n"
 18 fp1->_IO_buf_base)
 19 printf(" fp1->_IO_buf_end = 0x%x\n"
 20 fp1->_IO_buf_end)
 21 printf(" fp2->_IO_buf_base = 0x%x\n"
 22 fp2->_IO_buf_base)
 23 printf(" fp2->_IO_buf_end = 0x%x\n"
 24 fp2->_IO_buf_end)
 25 }
 

 $ fpopen
 Address of fp1 = 0x8049860
 
 fp1->_fileno = 0x3
 Address of fp2 = 0x80499d0
 fp2->_fileno = 0x4
 
 fp1->_IO_buf_base = 0x40019000
 fp1->_IO_buf_end = 0x4001a000
 fp2->_IO_buf_base = 0x4001a000
 fp2->_IO_buf_end = 0x4001b000
 

 $ strace fpopen 2>&1 | grep open
 open("/etc/passwd", O_RDONLY) = 
 open("/etc/mtab", O_RDONLY) = 
 $ strace fpopen 2>&1 | grep read
 read(3, "root:x:0:0:root:/root:/bin/bash\n"..., 4096) = 827
 read(4, "/dev/hda6 / ext2 rw 0 0 none /pr"..., 4096) = 157
 

There are two additional calls that can be invoked to open a file stream, namely fdopen()and freopen():

 #include < stdio.h>
 
 FILE *fdopen (int fildes, const char *mode)
 FILE *freopen (const char *filename,
 const char *mode, FILE *stream)
 

The freopen() function opens the file whose name is pointed to by filename and associates the stream pointed to by stream with it. The original stream (if it exists) is first closed. This is typically used to associate a file with one of the predefined streams, standard input, output, or error. For example, if the caller wishes to use functions such as printf() that operate on standard output by default, but also wants to use a different file stream for standard output, this function achieves the desired effect.

Standard I/O Library Buffering

The ANSI C standard dictates that standard input and output should be fully buffered while standard error should be unbuffered. Typically, standard input and output are set so that they are line buffered for terminal devices and fully buffered otherwise.

The setbuf()and setvbuf()functions can be used to change the buffering characteristics of a stream as shown:

 #include < stdio.h>
 
 void setbuf(FILE *stream, char *buf)
 int setvbuf(FILE *stream, char *buf, int type, size_t size)
 

The setvbuf() function can be called at any stage to alter the buffering characteristics of the stream. The type argument can be one of _IONBF (unbuffered), _IOLBF (line buffered), or _IOFBF (fully buffered). The buffer specified by the bufargument must be at least sizebytes. Prior to the next I/O, this buffer will replace the buffer currently in use for the stream if one has already been allocated. If bufis NULL, only the buffering mode will be changed.

Whether full or line buffering is used, the fflush() function can be used to force all of the buffered data to the file referenced by the stream as shown:

 #include < stdio.h>
 
 int fflush(FILE *stream)
 

Reading and Writing to/from a Stream

 1 #include < stdio.h>
 2 
 3 main() 
 4 { 
 5 FILE *fp; 
 6 char c; 
 7 
 8 fp = fopen("/etc/passwd", "r")
 9 printf("address of fp = 0x%x\n", fp)
 10 printf(" fp->_fileno = 0x%x\n", fp->_fileno)
 11 printf(" fp->_IO_buf_base = 0x%x\n", fp->_IO_buf_base)
 12 printf(" fp->_IO_read_ptr = 0x%x\n", fp->_IO_read_ptr)
 13
 14 c = getc(fp)
 15 printf(" fp->_IO_buf_base = 0x%x (size = %d)\n"
 16 fp->_IO_buf_base,
 17 fp->_IO_buf_end fp->_IO_buf_base)
 18 printf(" fp->_IO_read_ptr = 0x%x\n", fp->_IO_read_ptr)
 19 c = getc(fp)
 20 printf(" fp->_IO_read_ptr = 0x%x\n", fp->_IO_read_ptr)
 21 }
 

 $ fpinfo
 Address of fp = 0x8049818
 fp->_fileno = 0x3
 fp->_IO_buf_base = 0x0
 fp->_IO_read_ptr = 0x0
 fp->_IO_buf_base = 0x40019000 (size = 4096)
 fp->_IO_read_ptr = 0x40019001
 fp->_IO_read_ptr = 0x40019002
 

 $ strace fpinfo
 ..
 open("/etc/passwd", O_RDONLY) = 
 ..
 fstat(3, st_mode=S_IFREG_0644, st_size=788, ...) = 
 ..
 read(3, "root:x:0:0:root:/root:/bin/bash\n"..., 4096) = 788
 

The following example provides a simple cp program showing the effects of using fully buffered, line buffered, and unbuffered I/O. The buffering option is passed as an argument. The file to copy from and the file to copy to are hard coded into the program for this example.

 1 #include < time.h>
 2 #include < stdio.h>
 4 main(int argc, char **argv)
 5 {
 time_t time1, time2;
 7 FILE *ifp, *ofp; 
 8 int mode; 
 9 char c, ibuf[16384], obuf[16384]; 
 10 
 11 if (strcmp(argv[1], "_IONBF") == 0) {
 12 mode = _IONBF;
 13 } else if (strcmp(argv[1], "_IOLBF") == 0) {
 14 mode = _IOLBF;
 15 } else 
 16 mode = _IOFBF;
 17 
 18
 19 ifp = fopen("infile", "r")
 20 ofp = fopen("outfile", "w")
 21
 22 setvbuf(ifp, ibuf, mode, 16384)
 23 setvbuf(ofp, obuf, mode, 16384)
 24
 25 time(&time1)
 26 while ((c = fgetc(ifp)) != EOF) {
 27 fputc(c, ofp)
 28 }
 29 time(&time2)
 30 fprintf(stderr, "Time for %s was %d seconds\n", argv[1]
 31 time2 - time1)
 32 }
 

 $ ls -l infile
 -rw-r--r-1 spate fcf 5508000 Jun 29 15:38 infile
 $ wc -l infile
 68000 infile
 $ ./fpcp _IONBF
 Time for _IONBF was 35 seconds
 $ ./fpcp _IOLBF
 Time for _IOLBF was 3 seconds
 $ ./fpcp _IOFBF
 Time for _IOFBF was 2 seconds
 

 ..
 open("infile", O_RDONLY) = 
 open("outfile", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 
 time([994093607]) = 994093607
 read(3, "0", 1) = 
 write(4, "0", 1) = 
 read(3, "1", 1) = 
 write(4, "1", 1) = 
 ..
 

 ..
 open("infile", O_RDONLY) = 
 open("outfile", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 
 time([994093688]) = 994093688
 read(3, "01234567890123456789012345678901"..., 16384) = 16384
 write(4, "01234567890123456789012345678901"..., 81) = 81
 write(4, "01234567890123456789012345678901"..., 81) = 81
 write(4, "01234567890123456789012345678901"..., 81) = 81
 ..
 

 open("infile", O_RDONLY) = 
 open("outfile", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 
 read(3, "67890123456789012345678901234567"..., 4096) = 4096
 write(4, "01234567890123456789012345678901"..., 4096) = 4096
 read(3, "12345678901234567890123456789012"..., 4096) = 4096
 write(4, "67890123456789012345678901234567"..., 4096) = 4096
 

Seeking through the Stream

 #include < stdio.h>
 
 int fseek(FILE *stream, long int offset, int whence)
 

  1 #include < stdio.h>
  3 main()
  4 {
 5 FILE *fp; 
 6 char c; 
 7
 8 fp = fopen("infile", "r")
 9 printf("address of fp = 0x%x\n", fp)
 10 printf(" fp->_IO_buf_base = 0x%x\n", fp->_IO_buf_base)
 11 printf(" fp->_IO_read_ptr = 0x%x\n", fp->_IO_read_ptr)
 12
 13 c = getc(fp)
 14 printf(" fp->_IO_read_ptr = 0x%x\n", fp->_IO_read_ptr)
 15 fseek(fp, 8192, SEEK_SET)
 16 printf(" fp->_IO_read_ptr = 0x%x\n", fp->_IO_read_ptr)
 17 c = getc(fp)
 18 printf(" fp->_IO_read_ptr = 0x%x\n", fp->_IO_read_ptr)
 19 }
 
 By calling getc(), a 4KB read is used to fill up the buffer pointed to by 
 _IO_buf_base. Because only a single character is returned by getc(), the read 
 pointer is only advanced by one. The call to fseek() modifies the read pointer as 
 shown below: 
 
 $ fpseek
 Address of fp = 0x80497e0
 fp->_IO_buf_base = 0x0
 fp->_IO_read_ptr = 0x0
 fp->_IO_read_ptr = 0x40019001
 fp->_IO_read_ptr = 0x40019000
 fp->_IO_read_ptr = 0x40019001
 
 
 Note that no data needs to be read for the second call to getc(). Here are the 
 relevant system calls: 
 
 open("infile", O_RDONLY) = 
 fstat64(1, st_mode=S_IFCHR_0620, st_rdev=makedev(136, 0), ...) = 
 read(3, "01234567890123456789012345678901"..., 4096) = 4096
 write(1, ...) # display _IO_read_ptr
 _llseek(3, 8192, [8192], SEEK_SET) = 
 write(1, ...) # display _IO_read_ptr
 read(3, "12345678901234567890123456789012"..., 4096) = 4096
 write(1, ...) # display _IO_read_ptr
 
 
 The first call to getc() results in the call to read(). Seeking through the stream 
 results in a call to lseek(), which also resets the read pointer. The second call to 
 getc()then involves another call to read data from the file. 
 

 There are four other functions available that relate to the file position within the 
 stream, namely: 
 
 #include < stdio.h>
 
 long ftell( FILE *stream)
 void rewind( FILE *stream)
 int fgetpos( FILE *stream, fpos_t *pos)
 int fsetpos( FILE *stream, fpos_t *pos)
 
 
 
 The ftell()function returns the current file position. In the preceding example 
 following the call to fseek(), a call to ftell() would return 8192. The 
 rewind()function is simply the equivalent of calling: 
 
 	fseek(stream, 0, SEEK_SET)
 
 
 The fgetpos() and fsetpos() functions are equivalent to ftell() and 
 fseek() (with SEEK_SET passed), but store the current file pointer in the 
 argument referenced by pos. 
 

 Summary 
 

 There are numerous functions provided by the standard I/O library that often 
 reduce the work of an application writer. By aiming to minimize the number of 
 system calls, performance of some applications may be considerably improved. 
 Buffering offers a great deal of flexibility to the application programmer by 
 allowing finer control over how I/O is actually performed. 
 

 This chapter highlighted how the standard I/O library is implemented but 
 stops short of describing all of the functions that are available. Richard Stevens 
 book Advanced Programming in the UNIX Environment [STEV92] provides more 
 details from a programming perspective. Herbert Schildts book The Annotated 
 ANSI C Standard [SCHI93] provides detailed information on the stdio library as 
 supported by the ANSI C standard. 
 

 Оставьте свой комментарий !

Ваше имя:
Комментарий:
Оба поля являются обязательными 

 Автор 
 Комментарий к данной статье