Quick Anatomy of a Filesystem Type

The role of a filesystem type is to perform the low-level tasks used to map the relatively high level VFS operations on the physical media (disks, network or whatever). The VFS interface is flexible enough to allow support for both conventional \ filesystems and exotic situations such as the <#2545#> msdos<#2545#> and <#2546#> umsdos<#2546#> types. Each fs-type is made up of the following items, in addition to its own directory: The own directory for the fs type contains all the real code, responsible of inode and data management.

#tex2html_wrap2960#

We'll now look at the internal workings of the VFS mechanism, and the <#2560#> Minix<#2560#> filesystem source is used as a working example. I chose the <#2561#> Minix<#2561#> type because it is small but complete; moreover, any other fs type in \ derives from the <#2562#> Minix<#2562#> one. The <#2563#> ext2<#2563#> type, the de-facto standard in recent \ installations, is much more complex than that and its exploration is left as an exercise for the smart reader. When a minix-fs is mounted, <#2564#> minix_read_super<#2564#> fills the <#2565#> super_block<#2565#> structure with data read from the mounted device. The <#2566#> s_op<#2566#> field of the structure will then hold a pointer to <#2567#> minix_sops<#2567#>, which is used by the generic filesystem code to dispatch superblock operations. Chaining the newly mounted fs in the global system tree relies on the following data items (assuming <#2568#> sb<#2568#> is the <#2569#> super_block<#2569#> structure and <#2570#> dir_i<#2570#> points to the inode for the mount point):

Unmounting will eventually be performed by <#2579#> do_umount<#2579#>, which in turn invokes <#2580#> minix_put_super<#2580#>. Whenever a file is accessed, <#2581#> minix_read_inode<#2581#> comes into play; it fills the system-wide <#2582#> inode<#2582#> structure with fields coming form <#2583#> minix_inode<#2583#>. The <#2584#> inode-;SPM_gt;i_op<#2584#> field is filled according to <#2585#> inode-;SPM_gt;i_mode<#2585#> and it is responsible for any further operation on the file. The source for the Minix functions just described are to be found in <#2586#> fs/minix/inode.c<#2586#>. The <#2587#> inode_operations<#2587#> structure is used to dispatch inode operations (you guessed it) to the fs-type specific kernel functions; the first entry in the structure is a pointer to a <#2588#> file_operations<#2588#> item, which is the data-management equivalent of <#2589#> i_op<#2589#>. The Minix fs-type allows three instances of inode-operation sets (for directories, for files and for symbolic links) and two instances of file-operation sets (symlinks don't need one). Directory operations (<#2590#> minix_readdir<#2590#> alone) are to be found in <#2591#> fs/minix/dir.c<#2591#>; file operations (read and write) appear within <#2592#> fs/minix/file.c<#2592#> and symlink operations (reading and following the link) in <#2593#> fs/minix/symlink.c<#2593#>. The rest of the minix directory implements the following tasks: %