Page 456 - DCAP103_Principle of operating system
P. 456

Unit 14: Case Study of Linux Operating System



            The basic idea behind this type of file systems is to maintain a journal, which describes all file   Notes
            system operations in a sequential order. By sequentially writing out and changes to the file system
            data or metadata (i-nodes, superblock, etc.), the operations do not suffer from the overheads
            of disk head movement during random disk accesses. Eventually, the changes will be written
            out, committed, to the appropriate disk location, and the corresponding journal entries can be
            discarded.
            If a system crash or power failure occurs before the changes are committed, during restart, the
            system will detect that the file system was not unmounted properly, will traverse the journal,
            and apply the file system changes described in the journal log.
            Ext3 is designed to be highly compatible with ext2, and in fact, all core data structures and disk
            layout are the same in both systems. Furthermore, a file system which has been unmounted as an
            ext2 system, can be subsequently mounted as an ext3 system and offer the journaling capability.

            The  journal  is  a  file  used  as  a  circular  buffer.  It  may  be  stored  on  the  same  or  separate
            device from the main file system. Since the journal operations are not “journalled”
            themselves,  these  are  not  handled  by  the  same  ext3  file  system.  Instead,  a  separate  JBD
            (Journaling  Block  Device) is used to perform the journal read/write operations. JBD
            supports  three  main  data  structures:  log  record,  atomic  operation  handle,  and  transaction.
            A  log  record  describes  a  low  level  file  system  operation,  typically  resulting  in  changes
            within  a  block.  Since  a  system  call  such  as  write  includes  changes  at  multiple  places  —
            i-nodes,  existing  file  blocks,  new  file  blocks,  list  of  free  blocks,  etc.,  related  log  records  are
            grouped in atomic operations. Ext3 notifies JBD of the start and end of a system call processing,
            so that JBD can ensure that either all log records in an atomic operation are applied, or none
            of them. Finally, primarily for efficiency reasons, JBD treats collections of atomic operations as
            transactions. Log records are stored consecutively within a transaction. JBD will allow portions
            of the journal file to be discarded only after all log records belonging to a transaction are safely
            committed to disk.
            Since writing out a jog entry for each disk change may be costly, ext3 may be configured to keep
            a journal of all disk changes, or only of changes related to the file system metadata (the i-nodes,
            superblocks, bitmaps, and so on). Journaling metadata only introduces fewer system overheads
            and results in better performance, however does not make any guarantees against corruption
            of file data. Several other journaling file systems maintain logs of only metadata operations:
            (e.g., SGI’s XFS).
            14.6.7  /proc File System

            Another Linux file system is the /proc (process) file system, an idea originally devised in the 8th
            edition of UNIX from Bell Labs and later copied in 4.4BSD and System V.  However, Linux extends the
            idea in several ways. The basic concept is that for every process in the system, a directory is created
            in /proc. The name of the directory is the process PID expressed as a decimal number. for example,
            /proc/619 is the directory corresponding to the process with PID 619. In this directory files that
            appear to contain information about the process, such as its command line, environment strings,
            and signal masks. In fact, these files does not exist on the disk. When they are read, the system
            retrieves the information from the actual process as needed and returns it in a standard format.
            Many of the Linux extensions relate to other files and directories located in /proc. They contain
            a wide variety of information about the CPU, disk partitions, devices, interrupt vectors, kernel
            counters, file systems, loaded modules, and much more. Unprivileged user programs may read
            much of this information to learn about system behavior in a safe way. Some of these files may
            be written to in order to change system parameters.



                                             LOVELY PROFESSIONAL UNIVERSITY                                   449
   451   452   453   454   455   456   457   458   459   460   461