The document discusses lower-level file system algorithms and the concept of inodes, which are critical structures that contain metadata about files and directories, including permissions and data block locations. It explains the differences between disk inodes and in-core inodes, as well as algorithms like iget and iput for managing inodes, along with methods for accessing files and converting file byte offsets into physical disk blocks using the bmap algorithm. Additionally, it highlights the role of directories in the file system structure and the namei algorithm for converting path names to inode numbers.

1. Operating Systems Design (OSD)
Course Outcome ( CO ) 1
session – 7
Lower Level File System Algorithms
iget, iput, bmap, namei

3. Inodes:
 The inode, short name of index node is a data structure in a File System that
describes file system object like file or a directory.
 Each inode stores the attributes and disk block locations of the object’s data.
 The attributes include metadata, owner of the file, and the access
permissions.
 Inodes exist in a static form on disk. Kernel reads them into an in-core inode to
manipulate them.
 The in-core inode is the inode that is stored in memory by the kernel.
 It is the copy of the disk inode when a file opened.

4. Fields in the disk inode:
 File owner identifier – file owner is divided into
individual owner and a group owner.
 File type – files may be of regular files, directories,
or special files
 File access permissions – the system protects the
file according to three classes by giving access
permissions such as read, write and execute the
file.
 File access times – gives the time when the file
was modified, last accessed and when the inode
was last modified.
 Number of links to the file – it represents the
number of names the file has in the directory
hierarchy.
 Table of disk blocks – the data blocks where the
content of the file is saved

5.  The inode does not specify the path names that access the file.
 The contents of the file changes when writing it, but the contents of the inode are
changed when the contents of the file are changed or when the owner,
permissions or links are changed.
 Changing the contents of a file implies the change to the inode, but changing the
contents of inode does not imply the change in the contents of a file.

6. In-core Inode:
 The in-core inode is the inode that is stored in memory by the kernel.
 It stores the disk inode into the memory when the file is opened.
 It contains the following fields in addition to the fields of disk inode.
 Status – it indicates whether the inode is locked, process waiting, in-core
representation when there is a change in file data, mount point.
 Logical device number – the device number of the file.
 Inode number – the disk inode number of the file.
 Pointers to other in-core inodes – the links to inodes on hash queues for
finding the free inode.
 Reference count – indicates the number of instances the file is active that is
opened.

7.  Most of the fields in the in-core inode are similar to the buffer header.
 The management of both is similar.
 The most striking difference between in-core inode and the buffer header is the
reference count.
 Reference count counts the number of active instances of the file.
 An inode is on the free list if its reference count is zero, i.e., the kernel can
reallocate the in-core inode to another disk inode.
 A buffer has no reference count, if the buffer is free then it will be on the free list
if and only if it is unlocked.

8. Accessing inodes:
 The kernel identifies a particular inode by its file system and inode number
and allocates in-core inodes at the request of higher-level algorithms.
 The algorithm iget allocates an in-core copy of an inode.
 It is similar to the getblk algorithm for finding a disk block in the buffer cache.
 After accessing the inode, the kernel reads the disk copy of the new inode into
the in-core copy.
 As the kernel knows the inode number and the logical device, it computes the
logical disk block that contains the inode based on the number of inodes fit
into disk block.

9.  When the kernel knows the device and disk block number, it reads the block
using the bread algorithm and computes the byte offset of the inode in the block
using the formula
 The kernel removes the in-core inode from the free list, places it on the hash
queue and sets its in-core reference count to 1.
 The file type, owner, permissions, link count, file size and the table of contents
are copied from the disk inode to the in-core inode and returns a locked inode.
 The iget algorithm is as given.

10.  The iget algorithm is divided into four scenarios
 The kernel finds the inode in inode cache and it is on inode free list
 Remove free list
 Increment inode reference count
 The kernel cannot find the inode in inode cache so it allocates a
inode from inode free list
 Remove new inode from free list
 Reset inode number and file system
 Remove inode from old hash queue, place on new one
 Read inode from disk (algorithm bread)
 Initialize inode
 The kernel cannot find the inode in inode cache but finds the free
list empty.
 Returns error
 The kernel finds the inode in inode cache but it was locked.
 Sleep until inode becomes unlocked.

11. First scenario:
• The kernel maps the device number and inode number into a hash queue and
searches the queue for the inode.
• If the inode is found in the inode cache, it searches the free list.
• If the inode is found in the inode cache and also in the free list,
• Then it removes the inode from free list and locks it.
• The kernel reads the disk copy of the new inode into the in-core copy.

12. Second scenario
 If inode is not found in the inode cache and not in the free list,
 It allocates one from the free list and locks it.
 Now the kernel reads the disk copy of the new inode into the in-core copy.
Third Scenario:
• If the kernel cannot find the inode in inode cache,
• If the free list is empty, then
• The kernel reports an error.

13. Fourth Scenario:
• If the kernel finds the inode in inode cache and it is locked,
• The process goes to a sleep waiting for a free inode to be unlocked.
• The process will have control over the allocation of inodes at user level.
• But the kernel cannot guarantee when an inode will be available in the free list.
• So, the process that goes to sleep waiting for a free inode to become available,
may never wake up.
• Without leaving such process in hanging, the kernel fails the system call.

14. XV6 Implementation of iget:
5254 iget(uint dev, uint inum)
5255 {
5256 struct inode *ip, *empty;
5257
5258 acquire(&icache.lock);
5259
5260 // Is the inode already cached?
5261 empty = 0;
5262 for(ip = &icache.inode[0]; ip <
&icache.inode[NINODE]; ip++){
5263 if(ip−>ref > 0 && ip−>dev == dev &&
ip−>inum == inum){
5264 ip−>ref++;
5265 release(&icache.lock);
5266 return ip;
5267 }
5268 if(empty == 0 && ip−>ref == 0) //
Remember empty slot.
5269 empty = ip;
5270 }
5271
5272 // Recycle an inode cache entry.
5273 if(empty == 0)
5274 panic("iget: no inodes");
5275
5276 ip = empty;
5277 ip−>dev = dev;
5278 ip−>inum = inum;
5279 ip−>ref = 1;
5280 ip−>valid = 0;
5281 release(&icache.lock);
5282
5283 return ip;
5284 }
5285
5286 // Increment reference count for ip.
5287 // Returns ip to enable ip = idup(ip1)
idiom.
5288 struct inode*
5289 idup(struct inode *ip)
5290 {
5291 acquire(&icache.lock);
5292 ip−>ref++;
5293 release(&icache.lock);
5294 return ip;
5295 }

15. Releasing Inodes:
 When the kernel releases an inode, it decrements its in-core reference count.
 If the count drops to 0, the kernel writes the inode to disk.
 The kernel writes the inode to disk only if there is a difference between disk copy and in-core
copy.
 They both differ if the file content has changed, file access time has changed, or if the owner or
access permissions have changed.
 The kernel places the inode on the free list of inodes.
 The kernel can use the free inode again if it is needed.
 The kernel release all data blocks associated with the file.
 The inode is freed if the number of links to the file is 0.
 The iput algorithm is used to release the inodes.

17. XV6 Implementation of iput:
5357 void
5358 iput(struct inode *ip)
5359 {
5360 acquiresleep(&ip−>lock);
5361 if(ip−>valid && ip−>nlink == 0){
5362 acquire(&icache.lock);
5363 int r = ip−>ref;
5364 release(&icache.lock);
5365 if(r == 1){
5366 // inode has no links and no other references:
truncate and free.
5367 itrunc(ip);
5368 ip−>type = 0;
5369 iupdate(ip);
5370 ip−>valid = 0;
5371 }
5372 }
5373 releasesleep(&ip−>lock);
5374
5375 acquire(&icache.lock);
5376 ip−>ref−−;
5377 release(&icache.lock);
5378 }

18. Structure Of A Regular File:
 The inode contains the table of contents to locate a file’s data on disk.
 As each block on a disk is addressable by number, the table of contents consists
of a set of disk block numbers.
 If the data in a file were stored in a sequence of disk blocks, then the start block
address and the file size is sufficient to access all the data in the file.
 But this strategy is not allowed for simple extraction and contraction of files
without fragmentation of free storage area.
 And the kernel would have to allocate and reserve continuous space before
allowing operations that would increase the file size.

19.  For example, suppose a user creates three files, A, B, and C each consisting of
10 disk blocks of storage and they are allocated continuously as shown
• If the user wants to add 5 blocks of data to the file B, the kernel would have to
copy the file B to the place where there are 15 blocks available.
• And the previous space of file B would be left free until there comes a file which
needs 10 disk blocks.

20.  The kernel allocates file space one block at a time and allows the data in a file to be
spread throughout the file system.
 But this allocation scheme complicates the task of locating the data.
 The table of contents could consist of a list of block numbers.
 For example, if a logical block contains 1KB, then a file containing 10KB would require an
index of 10 block numbers.
 But a file containing 100KB would require 100 block numbers.
 By this allocation scheme, either the inode size would vary based on the file size or the
file size should be limited to a particular limit.
 So, to keep the inode structure small even to allow large files, the table of contents of disk
blocks use the structure as shown below.

21. • The System V Unix system runs with 13 entries in
the inode table.
• The blocks marked “direct” contain the numbers of
disk blocks that contain real data.
• The blocks marked “single indirect” refers to a
block that contain a list of direct block numbers.
• Similarly, the “double indirect” refers to a block of
indirect block numbers that refer the direct block
numbers.
• This method could be extended to support
quadruple indirect blocks, and so on.

22.  For example, assume that a logical block on the file system holds 1KB and that a
block number is addressable by a 32 bit (4B) integer.
 Then a block can hold up to 256 block numbers.
 The maximum number of bytes could be held in a file is calculated as shown
below.

23. bmap algorithm:
 The bmap algorithm is used to convert a file byte offset into a physical disk block.
 Processes access data in a file by byte offset.
 They view the file as a stream of bytes starting at byte address 0 and going up to the size of the
file.
 The kernel converts the user view of bytes into a view of blocks.
 The file starts at logical block 0 and continues to a logical block number corresponding to the file
size.
 The kernel accesses the inode and converts the logical file block into the appropriate disk block.
 The bmap algorithm is as given.

25.  Consider the block layout for the file byte offset in this figure, and assume that a
disk block contains 1024 bytes.
 If a process wants to access the byte offset 9000, the kernel calculates the byte
is in direct block 8 in the file starting from 0.
 It then accesses the block number 367.
 If a process wants to access byte offset 350,000 in the file,
 It must access the double indirect block with number 9156 from the figure.
 As indirect block has 256 block numbers, the first byte accessed in the double
indirect block is 272,384 (256K + 10K)
 As each single indirect block accesses 256KB, byte number 350,000 must be in
0th single indirect block of the double indirect block i.e., block number 331.
 As each direct block in single indirect block contains 1KB, byte number 77,616
of a single indirect block is in the 75th direct block in the single indirect block i.e.,
block number 3333.

26. XV6 Implementation of bmap:
5409 static uint
5410 bmap(struct inode *ip, uint bn)
5411 {
5412 uint addr, *a;
5413 struct buf *bp;
5414
5415 if(bn < NDIRECT){
5416 if((addr = ip−>addrs[bn]) == 0)
5417 ip−>addrs[bn] = addr = balloc(ip−>dev);
5418 return addr;
5419 }
5420 bn −= NDIRECT;
5421
5422 if(bn < NINDIRECT){
5423 // Load indirect block, allocating if necessary.
5424 if((addr = ip−>addrs[NDIRECT]) == 0)
5425 ip−>addrs[NDIRECT] = addr = balloc(ip−>dev);
5426 bp = bread(ip−>dev, addr);
5427 a = (uint*)bp−>data;
5428 if((addr = a[bn]) == 0){
5429 a[bn] = addr = balloc(ip−>dev);
5430 log_write(bp);
5431 }
5432 brelse(bp);
5433 return addr;
5434 }
5435
5436 panic("bmap: out of range");
5437 }

27. Directories:
 Directories are the files that give the file system a
hierarchical structure.
 A directory is a file whose data is a sequence of
entries, each consisting of an inode number and the
name of a file contained in the directory.
 A path name is a null terminated character string
divided into separate components by the slash (“/”)
character. Each component except the last must be
the directory.
 UNIX System V restricts component names to a
maximum of 14 characters, with a 2 byte entry for the
inode number, so the size of directory entry is 16
bytes.
 They play an important role in conversion if a file
name to an inode number.
 For example, the figure shows the directory layout for

28. Conversion of a Path Name to an Inode:
 The initial access to a file is by its path name.
 The kernel works internally with inodes rather than with path names.
 It converts the path names to inodes to access files.
 The algorithm namei parses the path name one component at a time, by
converting each component into an inode based on its name and the directory
being searched.
 It returns the inode of the input path name.
 All path names start from the current directory of the process unless the path
name starts with “/” the root.

29. Algorithm namei:
 Algorithm namei uses intermediate inodes as it parses a path name calling them as
working inodes.
 The inode where the search starts is the first working inode.
 During each iteration, the kernel makes sure that the working inode is a directory.
 The process must also have permission to search the directory.
 The user id of the process must match the owner or group id of the file and execute
permission must be granted.
 Otherwise search fails.
 The kernel does a linear search of the directory file associated with working inode.

30.  For example, consider path “/etc/passwd”
 Kernel starts parsing the path name starting with root directory “/”
 Working inode is root.
 Then search root for the directory etc.
 Kernel access data in root block by block until it finds etc.
 Now, working inode is etc.
 Search etc block by block until it finds passwd.
 Release an inode of etc, and set working inode as passwd.
 It returns current working inode.
 The namei algorithm is as given.

32. 5754 static struct inode*
5755 namex(char *path, int nameiparent, char *name)
5756 {
5757 struct inode *ip, *next;
5758
5759 if(*path == ’/’)
5760 ip = iget(ROOTDEV, ROOTINO);
5761 else
5762 ip = idup(myproc()−>cwd);
5763
5764 while((path = skipelem(path, name)) != 0){
5765 ilock(ip);
5766 if(ip−>type != T_DIR){
5767 iunlockput(ip);
5768 return 0;
5769 }
5770 if(nameiparent && *path == ’0’){
5771 // Stop one level early.
5772 iunlock(ip);
5773 return ip;
5774 }
5775 if((next = dirlookup(ip, name, 0)) == 0){
5776 iunlockput(ip);
5777 return 0;
5778 }
5779 iunlockput(ip);
5780 ip = next;
5781 }
5782 if(nameiparent){
5783 iput(ip);
5784 return 0;
5785 }
5786 return ip;
5787 }
5788
5789 struct inode*
5790 namei(char *path)
5791 {
5792 char name[DIRSIZ];
5793 return namex(path, 0, name);
5794 }
XV6 Implementation of namei: