Accessing filesystems

% It is well known that the filesystem is the most basic resource in a \ system, so basic and ubiquitous that it needs a more handy name --- I'll stick to the standard practice of calling it simply ``fs''. I'll assume the reader already knows the basic \ fs ideas --- access permissions, inodes, the superblock, <#2504#> mount<#2504#>ing and <#2505#> umount<#2505#>ing. Those concepts are well explained by smarter authors than me within the standard \ literature, so I won't duplicate their efforts and I'll stick to \ specific issues. % While the first Unices used to support a single fs type, whose structure was widespread in the whole kernel, today's practice is to use a standardized interface between the kernel and the fs, in order to ease data interchange across architectures. \ itself provides a standardized layer to pass information between the kernel and each fs module. This interface layer is called VFS, for ``virtual filesystem''. Filesystem code is therefore split into two layers: the upper layer is concerned with the management of kernel tables and data structures, while the lower layer is made up of the set of fs-dependent functions, and is invoked through the VFS data structures. All the fs-independent material resides in the <#2506#> fs/*.c<#2506#> files. They address the following issues: The VFS interface, then, consists of a set of relatively high-level operations which are invoked from the fs-independent code and are actually performed by each filesystem type. The most relevant structures are <#2530#> inode_operations<#2530#> and <#2531#> file_operations<#2531#>, though they're not alone: other structures exist as well. All of them are defined within <#2532#> include/linux/fs.h<#2532#>. The kernel entry point to the actual file system is the structure <#2533#> file_system_type<#2533#>. An array of <#2534#> file_system_type<#2534#>s is embodied within <#2535#> fs/filesystems.c<#2535#> and it is referenced whenever a <#2536#> mount<#2536#> is issued. The function <#2537#> read_super<#2537#> for the relevant fs type is then in charge of filling a <#2538#> struct super_block<#2538#> item, which in turn embeds a <#2539#> struct super_operations<#2539#> and a <#2731#> struct <#2540#> type<#2540#>_sb_info<#2731#>. The former provides pointers to generic fs operations for the current fs-type, the latter embeds specific information for the fs-type.

#tex2html_wrap2958#