+ All Categories
Home > Documents > The Monolithic Filesystem - people.cs.uchicago.edu

The Monolithic Filesystem - people.cs.uchicago.edu

Date post: 17-Oct-2021
Category:
Upload: others
View: 4 times
Download: 0 times
Share this document with a friend
32
CSPP 51081 Files and Directories 1 The Monolithic Filesystem bin etc dev home proc cdrom usr var ... bash passwd pts kaharris 1 assign1 include log 2 51081 status stdio.h wtmp assign1 notes The Linux Filesystem appears to be a single monolithic filesystem, but it is really a virtual filesystem pieced together by the Kernel using layers of abstraction: CSPP 51081 Unix Systems Programming
Transcript
Page 1: The Monolithic Filesystem - people.cs.uchicago.edu

CSPP 51081 Files and Directories 1'

&

$

%

The Monolithic Filesystem

z

rrddddddddddddddddddddddddddddd

rrffffffffffffffffffffff

tthhhhhhhhhhhhhhh

wwppppppp

�� &&MMMMMMM

++VVVVVVVVVVVVVVVV

,,YYYYYYYYYYYYYYYYYYYYYYYY

bin

��

etc

��dev

��

home

��

proc

��

cdrom

��

usr

��

var

��

. . .

bash passwd pts

��

kaharris

��

1

��

assign1 include

��

log

��2 51081

�� ''OOOOOOstatus stdio.h wtmp

assign1 notes

The Linux Filesystem appears to be a single monolithic filesystem, but it is really a

virtual filesystem pieced together by the Kernel using layers of abstraction:

CSPP 51081 Unix Systems Programming

Page 2: The Monolithic Filesystem - people.cs.uchicago.edu

CSPP 51081 Files and Directories 2'

&

$

%

Layers of abstraction

Block Physical Devices

��

Device Drivers

��

Individual Filesystems

��

Virtual Filesystem

��

User

CSPP 51081 Unix Systems Programming

Page 3: The Monolithic Filesystem - people.cs.uchicago.edu

CSPP 51081 Files and Directories 3'

&

$

%

System Calls: Program Interface with the Kernel

The Kernel maintains the Virtual Filesystem and allows programs to

access and modify this system through a system call interface. The Kernel

uses system calls by programs written in C to implement services on

behalf of the program.

Information about each file in the Virtual Filesystem is obtain by means

of thestat family of functions, and passed to programs using a C data

structure,struct stat

CSPP 51081 Unix Systems Programming

Page 4: The Monolithic Filesystem - people.cs.uchicago.edu

CSPP 51081 Files and Directories 4'

&

$

%

Obtaining File Information

CSPP 51081 Unix Systems Programming

Page 5: The Monolithic Filesystem - people.cs.uchicago.edu

CSPP 51081 Files and Directories 5'

&

$

%

stat: Obtaining inode information

SYNOPSIS

#include<sys/types.h>

#include<sys/stat.h>

int stat(const char *path, struct stat *buf);

int fstat(int fd, struct stat *buf);

int lstat(const char *path, struct stat *buf);

Return:

0 if OK -1 on error

stat chases down symbolic links, whilelstat provides file information about the

link itself. fstat accesses information about open files through a file descriptor.

The parameterbuf points to the structure of file information, if successful.

CSPP 51081 Unix Systems Programming

Page 6: The Monolithic Filesystem - people.cs.uchicago.edu

CSPP 51081 Files and Directories 6'

&

$

%

stat: Errors

errno

EACCES search permission onpath denied

EBADF fd is bad

ELOOP a loop exists in resolution ofpath

ENOTDIR a component alongpath is not a directory

ENOENT a component ofpath does not name an existing file

CSPP 51081 Unix Systems Programming

Page 7: The Monolithic Filesystem - people.cs.uchicago.edu

CSPP 51081 Files and Directories 7'

&

$

%

struct stat {

ino_t st_ino; /* file serial number (inode) */

dev_t st_dev; /* device id containing file */

dev_t st_rdev; /* device number for special files */

nlink_t st_nlink; /* number of hard links */

mode_t st_mode; /* file mode */

uid_t st_uid; /* user ID of owner of file */

gid_t st_gid; /* group ID of owner of file */

off_t st_size; /* file size if regular file */

/* path size if symbolic link */

unsigned long st_blksize; /* blocksize for filesystem I/O */

unsigned long st_blocks; /* number of blocks allocated */

time_t st_atime; /* time of last access */

time_t st_mtime; /* time of last modification */

time_t st_ctime; /* time of last inode change */

};

CSPP 51081 Unix Systems Programming

Page 8: The Monolithic Filesystem - people.cs.uchicago.edu

CSPP 51081 Files and Directories 8'

&

$

%

Identifying Files:

st ino, st dev andst rdev

CSPP 51081 Unix Systems Programming

Page 9: The Monolithic Filesystem - people.cs.uchicago.edu

CSPP 51081 Files and Directories 9'

&

$

%

Identifying Files

• Every file in the Virtual Filesystem is uniquely indentified by itsi-node number,st ino, and device number,st dev.

• An i-nodeis a data structure containing most of the informationabout a file and its data blocks. The inode number uniquely identifiesa file within a single filesystem. Th i-node contains file type, file size,access permission bits, owner and owner’s group, and pointers to thedata blocks for the file.

• The device number,st_dev is kept by the Virual Filesystem andidentifies the actual filesystem on which the file is located. Forexample, onadmiral the root directory has device number 769which it shares with/dev/tty (the terminal device), but thedirectorykaharris is located on the device with number 18, as areall the files in this directory.

CSPP 51081 Unix Systems Programming

Page 10: The Monolithic Filesystem - people.cs.uchicago.edu

CSPP 51081 Files and Directories 10'

&

$

%

Special Files

• Only character special files and block special files have meaningful

st_rdev values.

• The valuest_rdev has two components

– A major numberwhich provides the location of the code to

implement I/O operations for the device. For example, many

terminals onadmiral have a major number of 3. This is accessed

from st_rdev by the macromajor().

– A minor numberwhich identifies a particular device of a given

type. For example, each terminal will have a distinct minor

number. This is accessed fromst_rdev using the macro

minor().

CSPP 51081 Unix Systems Programming

Page 11: The Monolithic Filesystem - people.cs.uchicago.edu

CSPP 51081 Files and Directories 11'

&

$

%

Hard Link Count:

st nlink

CSPP 51081 Unix Systems Programming

Page 12: The Monolithic Filesystem - people.cs.uchicago.edu

CSPP 51081 Files and Directories 12'

&

$

%

Hard Link Count

• A directory in a filesystem consists of a file name and a pointer to theinode of the file name. (The only place the name of a file typicallyoccurs is in the directory –the i-node typically store this information.)

• When renaming a file, within the same filesystem, only the directoryentry is changed, no actual data is moved.

• The hard link count,st_nlink, is the number of directory entries inthe filesystem which point to the i-node.

• A file is deleted only when this hard link count goes to 0.

• The maximum number of hard links is given byLINK_MAX in<limits.h> and is 127 onadmiral.

• The link count only records the number of links within the filesystemin which the file is located.

CSPP 51081 Unix Systems Programming

Page 13: The Monolithic Filesystem - people.cs.uchicago.edu

CSPP 51081 Files and Directories 13'

&

$

%

Symbolic, or Soft, Links

• With asymbolic link(or soft link) the actual data of the file containsonly the path of the file within the Virtual Filesystem. The VirtualFilesystem uses this information to find the actual file referenced bythe symbolic link.

• Symbolic links are a special type of file, distinct from Regular files orDirectories.

• Creating or removing symbolic links do not change the link count,st_nlink of a file. Thus, a file may be removed (its link count goesto 0) and yet still have symbolic links pointing to it. These links arenow dangling pointers, pointing to nothing. If another file with thesame name and location is created, the symbolic link now points to it.

• Symbolic links can link to files in different filesystems in the VirualFilesystem.

CSPP 51081 Unix Systems Programming

Page 14: The Monolithic Filesystem - people.cs.uchicago.edu

CSPP 51081 Files and Directories 14'

&

$

%

File Type and Permission:

st mode

CSPP 51081 Unix Systems Programming

Page 15: The Monolithic Filesystem - people.cs.uchicago.edu

CSPP 51081 Files and Directories 15'

&

$

%

Layout of bits for st mode

F F F F S S S UR UW UX GR GW GX OR OW OX

F : File Type Bits

S : Special File Permission Bits

UR, UW, UX : User File Permission Bits

GR, GW, GX : Group File Permission Bits

OR, OW, OX : Other File Permission Bits

CSPP 51081 Unix Systems Programming

Page 16: The Monolithic Filesystem - people.cs.uchicago.edu

CSPP 51081 Files and Directories 16'

&

$

%

File Types: #include<sys/stat.h>

Type of File Macro Description

Regular S ISREG() File containing data in some form

Directory S ISDIR()File containing names of other files and

pointer to indode

Character S ISCHR() File for stream-like devices (like terminal)

Block S ISBLK() File for random-access devices (like disks)

FIFO S ISFIFO()File used for interprocess communication

(called a named pipe)

Socket S ISSOCK() File used for network communication

Symbolic Link S ISLNK() File that points to another file

CSPP 51081 Unix Systems Programming

Page 17: The Monolithic Filesystem - people.cs.uchicago.edu

CSPP 51081 Files and Directories 17'

&

$

%

File Permission Flags:#include<sys/stat.h>

Action User Group Other Directories Only

Read S_IRUSR S_IRGRP S_IROTH

Write S_IWUSR S_IWGRP S_IWOTH

Execute S_IXUSR S_IXGRP S_IXOTH

All S_IRWXU S_IRWXG S_IRWXO

Special S_ISUID S_ISGID S_ISVTX

CSPP 51081 Unix Systems Programming

Page 18: The Monolithic Filesystem - people.cs.uchicago.edu

CSPP 51081 Files and Directories 18'

&

$

%

Meaning of File Permission Flags

Flag Effect on Regular File

S IR[USR,GRP,OTH] permission to read file

S IW[USR,GRP,OTH] permission to write to file

S IX[USR,GRP,OTH] permission to execute file

S IRWX[U,G,O] permission to read,write and execute file

Flag Effect on Directory

S IR[USR,GRP,OTH] permission to read directory entries

S IW[USR,GRP,OTH] permission to remove and create files in directory

S IX[USR,GRP,OTH] permission to search for given pathname in directory

S IRWX[U,G,O] permission to read,remove,create and search directory

CSPP 51081 Unix Systems Programming

Page 19: The Monolithic Filesystem - people.cs.uchicago.edu

CSPP 51081 Files and Directories 19'

&

$

%

Usage of File Permissions

• To open a file bynamewe must have execute permission in eachdirectory mentioned inname, including the current directory. Thus,opening./nameis equivalent to openingname.

• To create a new file or delete a file, we must have write and executepermission in the directory. (But this is not needed for the file itself.)

• To list the files in a directory (as when we usels) must have readpermission for a directory to list the files in the directory.

• We must have read permission for a file to open the file for reading:O_RDONLY or O_RDWR.

• We must have write permission to open a file for writing or totruncate the file on opening:O_WRONLY or O_RDWR or O_TRUNC.

• We must have execution permission to execute a program.

CSPP 51081 Unix Systems Programming

Page 20: The Monolithic Filesystem - people.cs.uchicago.edu

CSPP 51081 Files and Directories 20'

&

$

%

Special File Permission Flags

• S ISUID: Set the effective user ID on execution of program to the

owner of the file. Used only for regular files when the owner has

execution permission.

• S ISGID: Set effective group ID on execution of program to the

group of the owner of the file. Used only for regular files when the

owner’s group has execution permission.

• S ISVTX (the sticky bit): Used only for directories. A file in the

directory can only be removed or renamed if the user has write

permission for the directory and either

– owns the file

– owns the directory

– is the superuser

CSPP 51081 Unix Systems Programming

Page 21: The Monolithic Filesystem - people.cs.uchicago.edu

CSPP 51081 Files and Directories 21'

&

$

%

File Ownership:

st uid andst uid

CSPP 51081 Unix Systems Programming

Page 22: The Monolithic Filesystem - people.cs.uchicago.edu

CSPP 51081 Files and Directories 22'

&

$

%

Ownership of New Files:st uid and st gid

• The User ID (st uid) and group ID (st gid) of a file is determinedwhen the file is created usingopen or creat.

• The user ID of the file is identical to the effective user ID of theprocess which creates it and the group ID of the file is usuallyidentical to the effective group ID of the process that creates it. (It ispossible to modify a directory so that the group ID of the file isidentical to the group ID of the directory.)

• We can obtain the User name through the standard library functiongetpwuid(3). Historically, this information is stored in ascii form inthe file/etc/passwd.

• We can obtain the Group name through the standard library functiongetgrgid(3). Historically, this information is stored in ascii form inthe file/etc/group.

CSPP 51081 Unix Systems Programming

Page 23: The Monolithic Filesystem - people.cs.uchicago.edu

CSPP 51081 Files and Directories 23'

&

$

%

Obtaining Information o ff the Password File

SYNOPSIS

#include <sys/types.h>

#include <pwd.h>

struct passwd *getpwuid(uid t uid);

struct passwd *getpwnam(const char *name);

Return:

pointer if OK NULL on error

errno

ENOMEM Insufficient memory to allocate passwd structure

CSPP 51081 Unix Systems Programming

Page 24: The Monolithic Filesystem - people.cs.uchicago.edu

CSPP 51081 Files and Directories 24'

&

$

%

struct passwd

struct passwd {

char *pw_name; /* user name */

char *pw_passwd; /* user password */

uid_t pw_uid; /* user id */

gid_t pw_gid; /* group id */

char *pw_gecos; /* real name */

char *pw_dir; /* home directory */

char *pw_shell; /* shell program */

};

CSPP 51081 Unix Systems Programming

Page 25: The Monolithic Filesystem - people.cs.uchicago.edu

CSPP 51081 Files and Directories 25'

&

$

%

Obtaining Information o ff the Group File

SYNOPSIS

#include <sys/types.h>

#include <grp.h>

struct group *getgrgid(gid t gid);

struct group *getgrnam(const char *name);

Return:

pointer if OK NULL on error

errno

ENOMEM Insufficient memory to allocate group structure

CSPP 51081 Unix Systems Programming

Page 26: The Monolithic Filesystem - people.cs.uchicago.edu

CSPP 51081 Files and Directories 26'

&

$

%

struct group

struct group {

char *gr_name; /* group name */

char *gr_passwd; /* group password */

gid_t gr_gid; /* group id */

char **gr_mem; /* group members */

};

CSPP 51081 Unix Systems Programming

Page 27: The Monolithic Filesystem - people.cs.uchicago.edu

CSPP 51081 Files and Directories 27'

&

$

%

File Size:

st size, st blksize andst blocks

CSPP 51081 Unix Systems Programming

Page 28: The Monolithic Filesystem - people.cs.uchicago.edu

CSPP 51081 Files and Directories 28'

&

$

%

File size in bytes:st size

• Thest_size is only meaningful for regular files, directories and

symbolic links.

• For a regular file the file size is the number of bytes from the start of

the file to the last written byte. It is possible for this value to be 0.

• For a directory, the file size is typically a multiple of 512, and is large

enough to store file name and inode.

• For a symbolic link the file size is the actual number of bytes in the

filename to which the link points.

CSPP 51081 Unix Systems Programming

Page 29: The Monolithic Filesystem - people.cs.uchicago.edu

CSPP 51081 Files and Directories 29'

&

$

%

Block Information: st blksize and st blocks

• The fieldst blksize is the preferred block size for I/O for the file.Usually, using this for your buffer size will minimize the amount oftime to read the file. It is file system dependent and depends on theactual device on which the filesystem is stored.

• The fieldst blocks is the actual number of 512-byte blocks that areallocated for storing data for the file. The size 512 bytes is commonto all files in the Virtual Filesystem.

• The number of 512-byte blocks,st blocks, allocated may be muchless then the recorded size,st size, as the file may contain holes.Recall, that usinglseek we can seek beyond the last written byteand write a new byte, producing a ”hole” in the file. The bytes in thehole areread as 0, but no space is actually allocated for these holesuntil bytes are actually written to them withwrite.

CSPP 51081 Unix Systems Programming

Page 30: The Monolithic Filesystem - people.cs.uchicago.edu

CSPP 51081 Files and Directories 30'

&

$

%

File Time Stamps:

st atime, st mtime andst ctime

CSPP 51081 Unix Systems Programming

Page 31: The Monolithic Filesystem - people.cs.uchicago.edu

CSPP 51081 Files and Directories 31'

&

$

%

File Time Stamps

Field Description Example

st_atime last-access time of file data read

st_mtime last-modification time of file data write

st_ctime last-change time of i-node status chmod

CSPP 51081 Unix Systems Programming

Page 32: The Monolithic Filesystem - people.cs.uchicago.edu

CSPP 51081 Files and Directories 32'

&

$

%

• The access time (st_atime) is updated whenever data from the file

is read, or the file is executed.

• The modification time (st_mtime) is updated whenever the contents

of the file has been modified.

• The access and modification times can be updated using the

commandtouch(1), which uses the system callutime(2).

• The change time of the inode (st_ctime) is only changed when the

contents of the i-node is changed. For example, changing

permissions withchmod or ownership withchown.

• You can usels to list the times:

ls -l : lists the modification time

ls -lu : lists access time

ls -lc : lists change time

CSPP 51081 Unix Systems Programming


Recommended