Scribd
Upload
33 views33 pages

System Calls For File Processing

This document provides an overview of several Linux system calls related to file I/O and management. It describes key system calls such as open(), read(), write(), close(), creat(), pipes(), dup(), and others. For each call it outlines the basic functionality, parameters, return values, and steps performed in the kernel. It also includes examples of usage and questions to test understanding. The document is intended to cover fundamental concepts for interacting with the Linux file system through system calls.

Uploaded by

87aditya87
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
33 views33 pages

System Calls For File Processing

This document provides an overview of several Linux system calls related to file I/O and management. It describes key system calls such as open(), read(), write(), close(), creat(), pipes(), dup(), and others. For each call it outlines the basic functionality, parameters, return values, and steps performed in the kernel. It also includes examples of usage and questions to test understanding. The document is intended to cover fundamental concepts for interacting with the Linux file system through system calls.

Uploaded by

87aditya87
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 33

Chapter-05

System Calls for the File System

By: Aditya Pancholi

Topics to cover

open()
read()
write()
lseek()
close()
creat()
mknod()
pipe()
mkfifo()
dup()
link()
unlink()

open()
fd = open ( pathname, flags, modes)
flags : type of open (reading or writing)
modes: file permissions if the file is being created.
return type: non negative integer
-1 in case of error
Steps:
convert file name to inode.
allocate file table entry, initialize count and offset.
allocate user descriptor entry.
free blocks in case of O_TRUNC

open() contd.
Example
Process A
fd1= open(/etc/passwd,O_RDONLY);
fd2= open(local,O_RDWR);
fd3= open(/etc/passwd,O_WRONLY);
Process B
fd1= open(/etc/passwd,O_RDONLY);
fd2= open(private,O_RDONLY);

open() contd.

read()
numbytes = read ( fd, buffer, count)
read() attempts to read upto count bytes from file descriptor
fd into the buffer starting at buffer
Steps:
get file table entry from user file descriptor table.
check file accessibility.
get u-area parameters.
(so that we dont have to pass them explicitly)
get inode from file table.
read data from the file
calculate disk blocks.
calculate offset in the blocks.
read and copy to user space.
repeat until count bytes are read.

read() contd.
u-area parameters

Single read() may involve reading multiple blocks.


Assume 1block= 1kb

read() contd.
Suppose the content of the file doc is abcd
What will be the output of?

read() contd.
What will be the output of?

read() contd.
What will be the output of?

write()
numbytes = write ( fd, buffer, count)
One or more blocks may be allocated for the use of indirect blocks or
data blocks.
Write to data block is delayed write. This may reduce the number of
disk writes.

read() and write() contd.


Inode is locked during the
duration of the read/write call.
Multiple processes may access
file data simultaneously.
What will be the output of?

Adjusting byte location


position = lseek (fd, offset, reference)
offset: offset of the pointer measured in bytes
reference: interpretation of the offset (relative, absolute etc)
return type: offset of the pointer from the beginning.
reference:
SEEK_SET: absolute offset
SEEK_CUR: relative to current location
SEEK_END: relative to the end of the file

Adjusting byte location contd.


What will be the output of?

close()
close(fd)
file table entry count is reduced.
if the count becomes 0, kernel frees the entry.
incore inode count is reduced.
if the count becomes 0, kernel frees the incore inode.
We didnt call close() in the programs earlier. What happened to
those descriptors?
When the process exists, kernel examines its active user file
descriptors and internally closes each one.

close() contd.

creat()
fd = creat (pathname, modes)
If no such file exists, kernel creates a new one.
If the file exists, kernel truncates the file (subject to permissions)
Steps:
Open the parent directory and see if the file exists.
In case of existing file:
check permissions.
In case if the file doesnt exists
get a free inode.
create entry in the parent directory.
allocate file table entry, initialize count.
In case of existing file, truncate contents, set size to 0.
return user file descriptor.

creat() contd.
What will be the output of?

mknod()
Its used for creating special files.
mknod (pathname, mode, dev)
mode: type and permissions
dev: major and minor device number in case of
block-special/character-special device.

Pipes
Allow data transfer between processes.
Types: named and unnamed.
named pipe: open()
unnamed pipe: pipe()
reading and writing: read()/write()
closing: close()

Unnamed pipes
pipe (pipefd[2])
pipefd[0]: read end
pipefd[1]: write end
Unidirectional data channel for IPC.
Data written from write end is buffered until it is read from the
read end.
Only related processes (descendent of the creator) can access the
pipe.

Unnamed pipes contd.


What will be the output of?

Unnamed pipes contd.


Steps:
Allocate a new inode for the pipe device.
Allocate 2 file table entries, one for reading and other for
writing.
Allocate 2 user file descriptors.
Set inode reference count to 2.
Set file table reference counts to 1.
Inode (not the file table) maintains the byte offset.
Random access to file pipe (lseek) is not possible.

Named pipes
It has a directory entry, is accessed by a pathname.
Exists permanently in file system hierarchy.
When all processes finish using the pipe, kernel reclaims its inode.
mknode (pathname, S_IFIFO|permissions, dev)
mkfifo (pathname, mode)

Named pipes contd.


What will be the output of?

Named pipes contd.


Kernel accesses the pipe exactly as it accesses data from regular
files.
Difference b/w storage allocation of pipes and regular files is that
only direct blocks are used in case of pipes.
Kernel manipulates these direct blocks as a circular queue,
maintaining read and write pointers.

Named pipes contd.


If a process tries to read more data than in the pipe, read will
return all the data in the pipe.
If the pipe is empty, reading process will sleep.
If no-delay option was set, read returns immediately.
If a process tries to write data to a pipe, and pipe cannot hold
all the data( not more than pipe total capacity), kernel marks the
inode and goes to sleep.
If process tries to write data greater than pipe total capacity, kernel
writes as much as possible and goes to sleep.

Closing pipes
If count of writers goes to 0, kernel awakens processes sleeping to
read data. They return their read calls with no data.
If count of readers goes to 0, kernel awakens process sleeping for
writing data to the pipe. Kernel sends signal indicating error.
If count of readers as well as writers reach 0, kernel frees disk blocks
and adjusts inode to indicate pipe is empty.

dup()
newfd = dup (oldfd)
Creates a copy of the file descriptor oldfd, using the lowest
numbered unused descriptor for the new descriptor.
After a successful return, the old and new file descriptors may be
used interchangeably.
They refer to the same open file description and thus share file
offset

dup() contd.

dup() contd.
What will be the output of?

Self Study topics


link system call (section 5.15)
unlink system call (section 5.16 upto 5.16.1)

You might also like