0% found this document useful (0 votes)
8 views6 pages

15 - Architect Korner.v File Management

The document discusses the importance of file management in software architecture, particularly on the Linux platform. It covers various types of files, file systems, and how Linux manages file storage and access through the Virtual File System (VFS). Additionally, it explains file synchronization mechanisms and system calls related to file operations.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
8 views6 pages

15 - Architect Korner.v File Management

The document discusses the importance of file management in software architecture, particularly on the Linux platform. It covers various types of files, file systems, and how Linux manages file storage and access through the Virtual File System (VFS). Additionally, it explains file synchronization mechanisms and system calls related to file operations.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 6

__________________________________________________________________________________ Architect Korner | Developers

Architect Korner
File Management
Software architects have a lot to do with reading and writing to databases, files,
devices and memory locations. Sending data in and out of files efficiently and
synchronously is very crucial in this field. Files are important not only from an
operating system perspective, but also for application programming. This article
introduces you to how architects use files to build their applications, middleware
and entire software products on the Linux platform.

T
he word ‘file’ originates files. There are different types of files—namely,
from the Latin filum, which regular or ordinary files, directory files, device
means a thread to hold loose files, link files, FIFO and socket files. Device
papers, especially arranged files are of two types: character and block
for reference. But in computing science, the device files. There are two types of link files:
word ‘file’ is used as a collection of data stored soft and hard [1] link files. In Linux, these files
with one name, which is the file name. Linux are arranged in an inverted tree data structure,
treats everything as a file. As an example, for easy maintenance.
data, devices, inter-process communication How are these files stored on a storage
mechanisms, and links are all dealt with as medium like a hard disk, USB storage or

www.LinuxForU.com | LINUX FOR YOU | SEPTEMBER 2010 | 47


Developers | Architect Korner ___________________________________________________________________________________________

CD-ROM? Linux uses a file system to manage file storage.


It supports various kinds of file systems [2], which are
depicted in Figure 1. Fundamentally, a file system is used
to organise, manipulate and retrieve stored files from a
storage medium. A comprehensive list of file systems,
with a brief description of each, can be found at [3] and a Third Extended Filesystem - ext3, Fourth Extended Filesystem –
comparison of different file systems with distinct features ext4, Reiser Filesystem - reiserfs, Amgia Fast Filesystem – affs,
is available at [4]. High Performance Filesystem - hpfs, IS0 9660 Filesystem - iso9660,
Minix Filesystem - Minix, FAT 16 bit - msdos, Virtual Fat Fielsystem
The Linux file system – vfat, Network Filesystem – NFS, Novell Filesystem - NCPFS,
Linux used to use the Third Extended file system (ext3) as
System V Filesystem – sysv, Uniform Filesystem – ufs, UMSDOS
the default file system, but recent kernel versions (2.6.28
onwards) use the Fourth Extended file system (ext4), Filesystem - umsdos, adfs, autofs, coda, coherent, cramfs, devpts,
which has many more desirable features compared to ext3. efs, hfs, jfs, ntfs, proc, qnx4, romfs, smbfs, tmpfs, udf, xenix, xfs
The complete features of the ext4 file system are available Silicon Graphics‘ IRIX, etc.,
at [5]. The major differences between ext3 and ext4 are
given in Table 1.

File Maximum file Maximum


Addressing
System system size file size Figure 1: Linux-supported file systems
16 Terabyte 2 Terabyte
Ext3 32-bit
(TB) (TB)
1 Exabyte 16 Terabyte
Ext4 48-bit
(EB) (TB)

Table 1: Comparison between ext3 and ext4 file systems

Executing fdisk /dev/<device file name> will list the


specified storage device's partitions, as shown in Figure 2.
Type L to obtain a list of known partition types, as shown
in Figure 3.
Normally, we use the mount command to mount a file
system, and the umount command to unmount the mounted
file system. However, we can configure the necessary file
systems to be automatically mounted during system start-up,
in the /etc/fstab file, and thus it is available for use as soon as
you log in to the system. Figure 2: Screenshot of fdisk /dev/sda
In our day-to-day life, we use different kinds of devices,
which in turn use different kinds of file systems. But Linux
uses a set of commands to access a file from any device or file
system. How is this possible? Linux accesses files through the
Virtual File System (VFS), which helps a user to access any
device with the same set of commands. VFS completely hides
the complexity of different file systems from the user. Figure
4 illustrates how a user accesses a file through VFS. Please
refer to Bovet and Cesati [6], to understand the internals of
the Linux file system.
The extundelete utility [7] can recover deleted files on
both ext3 and ext4 partitions. It uses the stored partition’s
journal information to do this.
Linux uses the resize2fs command-line utility to resize
(shrink or expand) existing ext2/ext3/ext4 file systems. If you
need a graphical utility, then gparted [8] can be used.
How is a file accessed by a process? Let us explore this. Figure 3: Screenshot—list of partition types

48 | SEPTEMBER 2010 | LINUX FOR YOU | www.LinuxForU.com


__________________________________________________________________________________________ Architect Korner | Developers
process' standard input (stdin), standard output (stdout)
Linux Commands (cp, mv, cat, touch, rm)
and standard error (stderr) respectively. Each process has
System Calls a file descriptor table, in which file descriptors are linked
to the file table, and to the inode table, subsequently. The
inode table stores a unique inode number for each file—so
Virtual File System
the total number of inodes in the table is equivalent to the
total number of files in the file system. Both the file table
Network Hard Disk Pseudo
and inode table are global tables. The given inode number
is routed to a data block on the hard disk/storage device,
where the file is stored. An overview of the file-opening
operation is shown in Figure 5.
NFS CIFS AFS ext4 NTFS UFS USB fs DOS /proc

Ethernet Hard Disk Flash Floppy RAM


Accessing device-special files
Figure 4: File system interface An ordinary file is stored in a hard disk data block, so we can
access it easily. But what happens with a device-special file?
fd Table
Since the device file is an entity used to access a device, if
you store/write any data to such a file, it will be sent to the
Process 1
0
File Table Inode Table
device, and not actually stored in a file. Device-special files
1 are in the /dev directory. Each device file is associated with
2
two numbers -- its major and minor numbers. The major
Opening mode,
Fil access permission, offset
3 e1

Process 2
Hard Disk number is used to identify the device type, and the minor
0
number is used to identify the instance of that device type. In
e2

1 Inode Number
Fil

2
3 this case, the inode table points to a switch table.
4 File 1 There are two switch tables in Linux—character and
Process 3
0
Data Blocks block device switch tables. Using the major number, the
1
2 File
3 switch table routes to a corresponding device driver, and the
3
…. device driver accesses the device. The complete flow of a user
Per Process Table Global File Table Global Inode Table process accessing a device is shown in Figure 6.

Figure 5: Interaction between processes and VFS objects (normal files) Linux system calls and strace
Linux has approximately 338 system calls. The system call
table is stored in unistd.h (/usr/src/linux-2.6.34/arch/x86/
inode Table Switch Table include/asm/unistd_32.h), and each system call is identified
by a unique system-call number. The file- and file-system-
related system calls are given in Table 2, with their call
File Table Device Driver numbers and a brief description of each call.
File system related system calls are available in Table 2
carried in the LFY CD bundled with this issue.
Let's say you want to trace a system call. You want
File descriptor Device
Device to find out which system calls an executable program
Table Access a Device Controller uses, how many times each system call is invoked, and
<< *** >>
how much time it takes for each invocation. We can get
#include <header.h>
main()
{ int I;
…… .
………… .....
………………
open( “device”, O_RDWR);
all this information from the strace command-line utility.
}
…………… .
For example, assume I want to create a named pipe, i.e., a
FIFO file, to communicate between two processes. To do
this, I'd run the mkfifo command. We can execute mkfifo
Figure 6: A user process accesses a device-special file via strace to obtain system call coverage information, as
shown in Figures 7 and 8.
Accessing normal/ordinary files Figure 8 shows the execution of strace –c –F mkfifo, and
Linux uses system calls to access a file. Let's begin with lists the information in a different format. Using this, we
the open system call, which is used to open a file, and can see which system calls were used by mkfifo, how many
which returns a file descriptor for access to the file. This times they were used, and how much time each call took.
file descriptor is an integer, and its value normally starts This reveals that mkfifo calls mknod to create a file; indeed,
at 3, since file descriptors 0, 1 and 2 are assigned for the mkfifo is just a wrapper around the mknod system call. Thus,

www.LinuxForU.com | LINUX FOR YOU | SEPTEMBER 2010 | 49


Developers | Architect Korner ___________________________________________________________________________________________

calling mknod instead of mkfifo will reduce the execution time


required to create the FIFO file.

The proc file system


The proc file system is one of the important virtual file
systems in Linux. It helps to maintain information about
currently running processes, system limitations, and system
information (like CPU, RAM, IRQ, etc). The output of the Figure 7: Running strace mkfifo
mount command lists this line for proc:

proc on /proc type proc (rw)

Here, the first proc is a pseudo-device created in


kernel memory. It is mounted at the /proc mount-point,
with the proc file-system type. The size of /proc is always
zero, because the data accessible via /proc is generated
on the fly. For example, if you execute a program (which
becomes a running process), then a directory is created in
/proc with the process identification number (PID). The
kernel maintains process-related information like its state,
PID, PPID, GID, fd table, and other parameters, in the
process ID directory, as long as the process is executing Figure 8: Running strace –c –F mkfifo
in the system. Once the process has ended, the directory
is removed. More complete information about /proc was
published in an earlier issue of LFY [9]. Process 2 Lock
Developers can also create their own entries in /proc to write( ) Record 1
store necessary information about their application programs, STOP
by interfacing the proc file system with a kernel module. An Record 2
excellent resource for more information on this is reference [10].
Process 1 Record 3
Synchronisation of a shared file read ( )
Linux is a multi-processing operating system, and if more than Record 4
one process wants to access the same file, or the same record STOP
in a file, it leads to a race condition. For example, if the first
Record 5
process opens the file, the kernel sets the file pointer to the file.
Unlock
Then, the second process opens the same file. The first pointer Process 3
is updated with the second pointer, so whatever you modify read ( ) File
with the first process will not be reflected in the file; only
modifications by the second process will be reflected. Figure 9: Non-shared lock—Sys V semaphore
This undesirable situation, caused by the race condition,
can be avoided if we synchronise the file with the help of and semaphore usage in programming at the user level, from
a suitable synchronisation mechanism. Linux supports all references [10-12].
kinds of synchronisation mechanisms, at user level as well
as kernel level. At the user level, we have semaphores to File-locking implementations: fcntl
synchronise a critical section, but to synchronise a file, The flock structure is used to declare and initialise a file lock.
it may not be a good choice. Instead, file locking is more The structure contains the following members:
suitable. In multi-threaded programming, pthread_mutex is
used to synchronise a thread. struct flock {
In this section, we discuss file-locking mechanisms: we short l_type ;
have two locking mechanisms, which can be implemented short l_whence ;
by flock and fcntl. The fcntl type of locking is more robust, off_t l_start ;
flexible and fine-grained. Figures 9 through 12 explain off_t l_len ;
the different types of locking architectures. You can get pid_t l_pid ;
information about the Linux kernel locking mechanisms, };

50 | SEPTEMBER 2010 | LINUX FOR YOU | www.LinuxForU.com


__________________________________________________________________________________________ Architect Korner | Developers

Process 7
read ( )
Process 6
Process 2 Lock
write ( )
write( ) Record 1 Lock record 1
STOP
Process 4 Record 1
STOP
read ( ) Unlock record 1
Record 2 Lock record 2
Process 5
Record 2
write ( )
Unlock record 2
Lock record 3
Process 1 Record 3
Process 1 Record 3
write( ) write ( ) Unlock record 3
Lock record 4
Record 4
Process 5
Process 3 Record 4
read ( ) Unlock record 4
STOP read ( ) Lock record 5
Record 5 Record 5
Unlock record 5
Unlock
Process 3
Process 4
write( ) File Process 2 File STOP
read ( )
write ( )

Figure 10: Non-shared lock—mandatory file locking Figure 12: Shared lock—advisory or record locking

Process 4
write ( )
Lock fcntl Implementation flock Implementation
Record 1 struct flock lock; flock ( fd, LOCK_EX );
STOP
lock.l_type = F_WRLCK; …….critical section……
Process 2 lock.l_whence = SEEK_SET;
Record 2
read ( ) lock.l_start = nth record; flock ( fd, LOCK_UN );
lock.l_len = sizeof (record);
lock.l_pid = getpid( );
Process 1 Record 3
fcntl ( fd, F_SETLKW, &lock ); flock ( fd, LOCK_SH );
read ( )
…….critical section…… …….critical section……
Record 4
lock.l_type = F_UNLCK; flock ( fd, LOCK_UN );

Record 5 fcntl ( fd, F_SETLK, &lock );

Process 3 Unlock
read ( )
File

Figure 11: Shared lock—mandatory file locking Figure 13: Sketch of file-locking implementation

Let's look at the members of the struct: If the process that is holding the lock exits abnormally,
ƒƒ l_type specifies the lock type, and is one of the then the kernel will release the lock, and the next
following: read lock (F_RDLCK), write lock (F_ deserving process can acquire the lock.
WRLCK) or unlock a locked file (F_UNLCK). A read If we want to lock the entire file, we set the l_start and l_
lock will allow many readers to access the file at the len fields to 0. To improve locking granularity, however, each
same time, but no writer is allowed. A write lock will process can lock a specific record, or range of bytes in a file,
allow only one writer at a time. by setting appropriate values in the l_start and l_len fields.
1. l_whence is used to set the file pointer relative to the Figure 13 explains how to approach this design of locking a
current cursor position. If, for example, you want to go specific record or byte, by the suitable setting of the l_start
to the starting location of a file, then pass SEEK_SET, or and l_len fields.
if the file is already open and you subsequently want to The locking and unlocking is done by calling the fcntl
set the lock from the current cursor position, then pass system call. Its syntax is:
SEEK_CUR. If you want to go to the end of the file, then
pass SEEK_END. int fcntl (int fd, int cmd, struct flock *lock);
2. l_start member of the structure is used to tell the starting
point of the file, which could be from the 10th byte. We have three commands: F_SETLKW, F_SETLK and
3. l_len is used to specify till what point you want to lock the F_GETLK to acquire, release or check the availability of
file. It could be till the 100th byte. the lock. The first two commands are used to acquire or
ƒƒ l_pid is the process ID of the process that holds the lock. release the lock, but the difference between them is that

www.LinuxForU.com | LINUX FOR YOU | SEPTEMBER 2010 | 51


Developers | Architect Korner ___________________________________________________________________________________________

SETLKW will wait till the lock is released, if it's held by • LOCK_UN (remove an existing lock)
another process, but SETLK will return with an error if the Examples of file-locking implementations of both fcntl
lock is not available. F_GETLK will just check if the lock and flock types are shown in Figure 13.
is available. To sum up, let's look at the procedure for lock usage:
a. Declare a lock
File-locking implementations: flock b. Initialise the lock
The usage of flock is simpler than fcntl. On the flip side, flock c. Lock the critical section
does not have many features that a developer needs. Use flock d. Unlock the critical section
just to lock or unlock, by passing a suitable operation flag. In this article, we have looked at how a file is accessed on
The flock command manages locks within shell scripts, or at the Linux platform, and its complete sequence. We showed
the command line. The flock system call is used to apply or different file-related system calls, and discussed how they
remove an advisory lock on an open file. Information on the work. We explained different file-synchronisation mechanisms
flock system call is provided below. available on Linux, and the procedures to access different
Syntax: kinds of files. This information is valuable to software
architects who create entire software products on the Linux
int flock (int fd, int operation); platform.

Available operations:
Acknowledgement
• LOCK_SH (shared lock, more than one process can hold)
The authors would like to acknowledge Krishna Sudhakaran for
• LOCK_NB (don’t block when locking)
his valuable assistance in the preparation of the view graphs.
• LOCK_EX (exclusive lock; only one process at a time)

References
1. Kernel Corner: Starting with Linux Device Drivers, by Dr B. Thangaraju, LINUX For You, May 2003, p 83
2. Linux supported file systems: http://www.linux-tutorial.info/modules.php?name=MContent&pageid=243
3. List of file systems: http://en.wikipedia.org/wiki/List_of_file_systems
4. A comparison of file systems: http://en.wikipedia.org/wiki/Comparison_of_file_systems
5. Ext4 fs features: http://kernelnewbies.org/Ext4
6. Understanding the Linux Kernel, (3rd Edition) by Daniel P. Bovet, Marco Cesati, O'Reilly Publications, 2005
7. extundelete details: http://extundelete.sourceforge.net/
8. gparted documentation: http://gparted.sourceforge.net/documentation.php
9. Kernel Corner: Examining Process Information, by Dr B. Thangaraju, LINUX For You, January 2004, pgs 84-87
10. Kernel Corner: Interfacing the proc file system with a kernel module, by Dr B. Thangaraju, LINUX For You, February 2004, pgs 90-92
11. Kernel Corner: Linux Kernel Locking Mechanisms for Kernel Programming, by Dr B. Thangaraju, LINUX For You, September 2003,
pgs 81-83;
12. Basics of System V Semaphore, by Dr B. Thangaraju, LINUX For You, July 2006, pgs 86-89;
13. The Intricacies of System V Semaphore, by V. Shobana and Dr B. Thangaraju, LINUX For You, April 2009, pgs 40-43.

By: Gururajan Narasimhan Erode and Dr B. Thangaraju


Gururajan Narasimhan Erode currently works with Wipro Technologies as a lead consultant in the Wireless and Embedded Domain. He has
16 years of experience after a masters degree in engineering, and has worked with various multinational companies in the USA, Germany
and India. Gururajan's specialisation is in wireless communication, algorithms and data structures, and Linux systems programming. He
can be reached at [email protected].
Dr B. Thangaraju received his Ph.D. in Physics and worked as a research associate in the Indian Institute of Science from 1996 to
2001. From 2001, he has been working at Wipro Technologies as a senior consultant, and his core expertise is in the Linux kernel and
embedded and real-time Linux. He has published more than 35 papers on Linux in renowned international and national journals, and
has presented more than 20 technical papers at national and international conferences. He can be reached at [email protected].

52 | SEPTEMBER 2010 | LINUX FOR YOU | www.LinuxForU.com

You might also like