Linux Kernel Architecture

Chapter 9: The Extended Filesystem Family

In this context, care should be exercised because of the structure ofUnixfilesystems, as explained in

Chapter 8. If hard links are used, users have access to inodes (and therefore to the associated data blocks)

under several names in the system. However, thenlinkcounter in the inode structure keeps a record of

how many hard links point to an inode.

The filesystem code decrements this counter by 1 each time a link to the inode is deleted. When the

counter value reaches 0, there are no remaining hard links to the inode, and it can therefore be finally

released. Once again it should be noted that only thecorresponding bit in the inode bitmap is set to 0; the

associated data are still present in the block and can potentially be used to reconstruct the file contents.

The data blocks associated with the inode have not yet been released. This is not done until all references

to the inode data structure have been returned withiput.

What is the difference between deleting a regular file and deleting a directory? Most of the above actions

(with the exception ofext2_empty_dir) do not specifically relate to directories and can be used for gen-

eral inode types. In fact, the procedure used to delete non-directories is very similar to the one described

above. Starting with theunlinksystem call, the VFSvfs_unlinkfunction is invoked to initiate the file-

specificinode_operations->unlinkoperation. For the Second Extended Filesystem, this operation is

ext2_unlink, which is described above. Everything said there also applies for deleting regular files,

links, and so on.

Removing Data Blocks

In the delete operations described above, the data blocks remain untouched, partly because of the hard

link problem. Removal of data blocks is closely associated with the reference counting of inode objects

because two conditions must be satisfied before the data blocks can actually be deleted:

1. The link counternlinkmust be zero to ensure that there are no references to the data in the
   filesystem.


2. The usage counter (i_count) of the inode structure must be flushed from memory.

The kernel uses theiputfunction to decrement the reference counter for the memory object. It therefore

makes sense to introduce a check at this point to establish whether the inode is still needed and to remove

it if not. This is a standard function of the virtual filesystem not discussed in detail here because the only

aspect of interest is that the kernel invokes theext2_delete_inodefunction to release the data associated

with the inode on the hard disk (iputalso returns memory data structures and memory pages reserved

for data). This function builds primarily on two other functions —ext2_truncate, which releases the

data blocks associated with the inode (regardless of whether the inode represents a directory or a regular

file); andext2_free_inode, which releases the memory space occupied by the inode itself.

Neither function deletes the space occupied on the hard disk or overwrites it with

null bytes. They simply release the corresponding positions in the block or inode

bitmap.

Since both functions reverse the technique used to create files, their implementation need not be discussed

here.