Stat, mmap, process syncing and file system interface Nezer J. Zaidenberg

Agenda We will discuss how files are accessed in UNIX We will discuss how files are accessed in UNIX Lots of system calls will be introduced. (most of them – reintroduced.) Lots of system calls will be introduced. (most of them – reintroduced.) We will also discuss shared memory and syncing between processes. We will also discuss shared memory and syncing between processes.

Prior knowladge open(2) and fopen(3) – open a file to read/write. open(2) and fopen(3) – open a file to read/write. close(2) and fclose(3) – close a file to read/write. close(2) and fclose(3) – close a file to read/write. read(2), write(2), fread(2), fwrite(2) read(2), write(2), fread(2), fwrite(2) opendir(3), readdir(3) – read directory contents opendir(3), readdir(3) – read directory contents All those are covered in K&R2 chapter 8 All those are covered in K&R2 chapter 8

Stat(2) Stat(2) is a system call used to learn about a file. Stat(2) is a system call used to learn about a file. Information received Information received Access permissions Access permissions Size Size Owner Owner Group Group File last access time, change time and modification time (change time = file information changed, mtime = content change) File last access time, change time and modification time (change time = file information changed, mtime = content change) Etc. Etc. Stat(2) returns a struct with all the file information Stat(2) returns a struct with all the file information

Stat(2) NAME stat, lstat, fstat -- get file status stat, lstat, fstat -- get file statusSYNOPSIS #include #include int stat(const char *path, struct stat *sb); int stat(const char *path, struct stat *sb); int lstat(const char *path, struct stat *sb); int lstat(const char *path, struct stat *sb); int fstat(int fd, struct stat *sb); int fstat(int fd, struct stat *sb);

Struct stat (1/2)) struct stat { struct stat { dev_t st_dev; /* device inode resides on */ dev_t st_dev; /* device inode resides on */ ino_t st_ino; /* inode's number */ ino_t st_ino; /* inode's number */ mode_t st_mode; /* inode protection mode */ mode_t st_mode; /* inode protection mode */ nlink_t st_nlink; /* number or hard links to the file */ nlink_t st_nlink; /* number or hard links to the file */ uid_t st_uid; /* user-id of owner */ uid_t st_uid; /* user-id of owner */ gid_t st_gid; /* group-id of owner */ gid_t st_gid; /* group-id of owner */ dev_t st_rdev; /* device type, for special file inode */ dev_t st_rdev; /* device type, for special file inode */

Struct stat (2/2) struct timespec st_atimespec; /* time of last access */ struct timespec st_atimespec; /* time of last access */ struct timespec st_mtimespec; /* time of last data modification */ struct timespec st_mtimespec; /* time of last data modification */ struct timespec st_ctimespec; /* time of last file status change */ struct timespec st_ctimespec; /* time of last file status change */ off_t st_size; /* file size, in bytes */ off_t st_size; /* file size, in bytes */ quad_t st_blocks; /* blocks allocated for file */ quad_t st_blocks; /* blocks allocated for file */ u_long st_blksize;/* optimal file sys I/O ops blocksize */ u_long st_blksize;/* optimal file sys I/O ops blocksize */ u_long st_flags; /* user defined flags for file */ u_long st_flags; /* user defined flags for file */ u_long st_gen; /* file generation number */ u_long st_gen; /* file generation number */ }; };

Access permission Like everything in the IDF file system permissions in UNIX is divided to 3 parts Like everything in the IDF file system permissions in UNIX is divided to 3 parts ME – what I can do. ME – what I can do. MY GROUP – (every user have a group) – what my group can do. MY GROUP – (every user have a group) – what my group can do. OTHER – what everybody else can do. OTHER – what everybody else can do.

ACCESS PERMISSIONS And of course what every body can do also divides to 3. And of course what every body can do also divides to 3. Permission to read (file contents, directory contents) Permission to read (file contents, directory contents) Permission to write (file contents, add files to directory) Permission to write (file contents, add files to directory) Permission to execute (file, cd to directory) Permission to execute (file, cd to directory) FILE SYSTEM PERMISSION ARE MANDATORY! FILE SYSTEM PERMISSION ARE MANDATORY! We use 3 octal digits to represent permissions. We use 3 octal digits to represent permissions. Read = 4, write =2 execute =1 we sum the permission number and get the digit Read = 4, write =2 execute =1 we sum the permission number and get the digit

Some examples Permissionmeaning 6446(=4+2) I can read and write My group and everybody else can read 777(7 = 4+2+1) everybody can read write and execute 705(7=4+2+1), 5=(4+1) I can read write and execute My group can’t do anything but other people can read and execute 700Only I can read, write and execute the file

lseek(2) Move to specific location on a file. Move to specific location on a file. Usage example: Usage example: Large database on a specific file Large database on a specific file User interested in a specific value User interested in a specific value lseek(2) to the right location and read the value lseek(2) to the right location and read the value

lseek(2) NAME lseek -- reposition read/write file offset lseek -- reposition read/write file offsetSYNOPSIS #include #include off_t off_t lseek(int fildes, off_t offset, int whence); lseek(int fildes, off_t offset, int whence);

creat(2) SYNOPSIS #include #include int int creat(const char *path, mode_t mode); creat(const char *path, mode_t mode); // Open can also be used for this file.

dup(2) SYNOPSIS #include #include int int dup(int oldd); dup(int oldd); int int dup2(int oldd, int newd); dup2(int oldd, int newd);

File locking Different flavours of UNIX offers different file locking. Different flavours of UNIX offers different file locking. Two system calls are used: Two system calls are used: flock(2) –on BSD UNIX (Mac OSX, FreeBSD, Darwin) flock(2) –on BSD UNIX (Mac OSX, FreeBSD, Darwin) fcntl(2) - on SVR4 UNIX (Linux, Solaris, HP-UX) fcntl(2) - on SVR4 UNIX (Linux, Solaris, HP-UX) File locking only works on processes not threads. File locking only works on processes not threads. Use fcntl(2) locking on TAU. Use fcntl(2) locking on TAU.

flock(2) SYNOPSIS #include #include #define LOCK_SH 1 /* shared lock */ #define LOCK_SH 1 /* shared lock */ #define LOCK_EX 2 /* exclusive lock */ #define LOCK_EX 2 /* exclusive lock */ #define LOCK_NB 4 /* don't block when locking */ #define LOCK_NB 4 /* don't block when locking */ #define LOCK_UN 8 /* unlock */ #define LOCK_UN 8 /* unlock */ int int flock(int fd, int operation); flock(int fd, int operation);

fcntl(2) SYNOPSIS #include #include int int fcntl(int fd, int cmd, int arg); fcntl(int fd, int cmd, int arg); OFTEN USED FOR FILE LOCKING ON SYS V SYSTEMS

Memory mapping mmap(2) mmap(2) munmap(2) munmap(2) msync(2) msync(2)

mmap(2) Maps a file to memory Maps a file to memory This memory can be shared (among process) or locked This memory can be shared (among process) or locked Check mprotect(2) for locking option (beyond our scope) Check mprotect(2) for locking option (beyond our scope) Use msync(2) to write changes Use msync(2) to write changes Use munmap(2) to write and free memory Use munmap(2) to write and free memory Homework : use read(2) and write(2) to copy file. Then use mmap and memory copy. What works faster? Homework : use read(2) and write(2) to copy file. Then use mmap and memory copy. What works faster?

mmap(2) NAME mmap -- map files or devices into memory mmap -- map files or devices into memorySYNOPSIS #include #include void * void * mmap(void *addr, size_t len, int prot, int flags, int fildes, off_t offset); mmap(void *addr, size_t len, int prot, int flags, int fildes, off_t offset);

munmap(2) NAME munmap -- remove a mapping munmap -- remove a mappingSYNOPSIS #include #include int munmap(void *addr, size_t len); int munmap(void *addr, size_t len);

msync(2) NAME msync -- synchronize a mapped region msync -- synchronize a mapped regionSYNOPSIS #include #include int msync(void *addr, size_t len, int flags); int msync(void *addr, size_t len, int flags);

Example (1/2) #include #include #include /* mmap() is defined in this header */ #include #include int main (int argc, char *argv[]) // will be used as cp source dest { int fdin, fdout; char *src, *dst; char *src, *dst; struct stat statbuf; fdin = open (argv[1], O_RDONLY); fdout = open (argv[2], O_RDWR | O_CREAT | O_TRUNC, FILE_MODE);

Example 2/2 fstat (fdin,&statbuf); // get size lseek (fdout, statbuf.st_size - 1, SEEK_SET); // go to the location corresponding to the last byte write (fdout, "", 1) // output file now the size of input file /* mmap the input and output file */ /* mmap the input and output file */ src = mmap (0, statbuf.st_size, PROT_READ, MAP_SHARED, fdin, 0); dst = mmap (0, statbuf.st_size, PROT_READ | PROT_WRITE, MAP_SHARED, fdout, 0); memcpy (dst, src, statbuf.st_size); } // if we wanted to write and continue we had to use munmap or msync

Sync ProcessThread Shared memoryShared memory via mmap(2) Everything is shared MutexMutex via flock(2)Mutex via pthread_mutex CondCond via socket and message passing Cond via pthread_cond

Why does mmap(2) and memcpy(2) works faster then read(2) and write(2) when copying files?

Explanation When read(2)ing and write(2) we copy from OS buffer to user buffers and back. When read(2)ing and write(2) we copy from OS buffer to user buffers and back. This copy is redundant. mmap(2) just use the OS buffers making less memory copies. Therefore, we should expect mmap to work faster. This copy is redundant. mmap(2) just use the OS buffers making less memory copies. Therefore, we should expect mmap to work faster.

Linking Symlink(2) Symlink(2) Link(2) Link(2) Create soft and hard link Create soft and hard link

Types of links Hard Link Hard Link new (additional) name for a file. new (additional) name for a file. File is stored once with two (or more) names. File is stored once with two (or more) names. No “master” and “slave” later. All names are equal. No “master” and “slave” later. All names are equal. Problems Problems Who is charged for the file for quota? Who is charged for the file for quota? How to save links after backup? How to save links after backup? Symbolic (soft) Link Symbolic (soft) Link New file contain path of linked file New file contain path of linked file Most API follow symbolic links by reading content and opening linked file Most API follow symbolic links by reading content and opening linked file If linked file is deleted – we have broken link. Link that points at nothing If linked file is deleted – we have broken link. Link that points at nothing

link(2) and unlink(2) Unlink – delete a directory entry. Removes a “link” from a directory. When all links are removed file is deleted. (most files are linked once) Unlink – delete a directory entry. Removes a “link” from a directory. When all links are removed file is deleted. (most files are linked once) Link – create a hard link – give a new name to a file. File now resides in both original and new directory. Link – create a hard link – give a new name to a file. File now resides in both original and new directory.

Unlink(2) NAME unlink -- remove directory entry unlink -- remove directory entrySYNOPSIS #include #include int int unlink(const char *path); unlink(const char *path);

link(2) NAME link -- make a hard file link link -- make a hard file linkSYNOPSIS #include #include int int link(const char *path1, const char *path2); link(const char *path1, const char *path2);

symlink(2) NAME symlink -- make symbolic link to a file symlink -- make symbolic link to a fileSYNOPSIS #include #include int int symlink(const char *path1, const char *path2); symlink(const char *path1, const char *path2);

Signals - revisitted Debt from homework

Set signal handler signal(3) – old interface signal(3) – old interface sigaction(2) – new interface (more generic) sigaction(2) – new interface (more generic) Those functions get signal numbers and signal handler function pointer Those functions get signal numbers and signal handler function pointer When signal is caught the function handler is called. When signal is caught the function handler is called.

Signal(3) SYNOPSIS #include #include void (* void (* signal(int sig, void (*func)(int)))(int); signal(int sig, void (*func)(int)))(int); //or in the equivalent but easier to read typedef'd version: //or in the equivalent but easier to read typedef'd version: typedef void (*sig_t) (int); typedef void (*sig_t) (int); sig_t sig_t signal(int sig, sig_t func); signal(int sig, sig_t func);

Sigaction(2) (1/2) SYNOPSIS #include #include struct sigaction { union { struct sigaction { union { void (*__sa_handler)(int); void (*__sa_handler)(int); void (*__sa_sigaction)(int, struct __siginfo *, void *); void (*__sa_sigaction)(int, struct __siginfo *, void *); } __sigaction_u; /* signal handler */ } __sigaction_u; /* signal handler */ int sa_flags; /* see signal options below */ int sa_flags; /* see signal options below */ sigset_t sa_mask; /* signal mask to apply */ sigset_t sa_mask; /* signal mask to apply */ }; };

Sigaction(2) 2/2 #define sa_handler __sigaction_u.__sa_handler #define sa_handler __sigaction_u.__sa_handler #define sa_sigaction __sigaction_u.__sa_sigaction #define sa_sigaction __sigaction_u.__sa_sigaction int int sigaction(int sig, const struct sigaction * restrict act, sigaction(int sig, const struct sigaction * restrict act, struct sigaction * restrict oact); struct sigaction * restrict oact);

Kill(2) SYNOPSIS #include #include int int kill(pid_t pid, int sig); kill(pid_t pid, int sig);

What you may do in a sig handler Signal handler are very low level code. They are invoked by the kernel, as an interrupt to the program (even while doing other system call) – some of you got EINTR on select(2) Therefore we must not get another interrupt on signal handler. Use only memory operation and non blocking system calls. (specifically avoid file I/O on signal hanglers) Getting another signal on signal handler may result in undefined behavior or even damned recursion

Things to specifically avoid Don’t call new process from signal handler. (if the process dies and you get SIGCHLD you will end up in damn recursion) Don’t call new process from signal handler. (if the process dies and you get SIGCHLD you will end up in damn recursion) Avoid calling syslog from signal handler. Avoid calling syslog from signal handler. Adding stuff to log queue in signal handler and deleting stuff from the queue later is good alternative. Adding stuff to log queue in signal handler and deleting stuff from the queue later is good alternative.

Interrupted system call You get EINTR on select(2) You get EINTR on select(2) Check chapter 10.5 in advanced programming in the unix environment Check chapter 10.5 in advanced programming in the unix environment Also do man select(2) and check EINTR Also do man select(2) and check EINTR Basically if you get a signal such a SIGCHLD select will fail. This is condition you have to check but you don’t have to die (actually you should not die) Basically if you get a signal such a SIGCHLD select will fail. This is condition you have to check but you don’t have to die (actually you should not die)