7

My question concerns the Linux source, and if it actually contains the code necessary, natively to mount, parse, and use a filesystem, or if that's added to the source.

If the Linux source contains code to parse and access/organize files through a file system and such, is it safe to say that the filesystem is controlled by a device driver coded in to Linux, or is this procedure differ based on things like distro, releases, etc.

How does Linux access files using a filesystem on other storage devices, i.e., how do userspace programs access proc, ext3, ext4, etc., and are ext3, ext4 considered "device drivers", since they operate directly with hardware, or do I have it wrong?

Megaloma
  • 87
  • 2
    Related: How does /proc/* work? on SuperUser. (Full disclosure: the link target accepted answer is mine.) – user Aug 14 '13 at 21:39
  • 2
    Your answer is good, very helpful, but it uses too many blanket terms for things you seem to not have the knowledge to explain in more detail. First of all, I never asked about proc, I asked about the mounting process of drives and filesystems. – Megaloma Aug 14 '13 at 21:47
  • 4
    @Megaloma "but it uses too many blanket terms for things you seem to not have the knowledge to explain in more detail." there's no cause to be rude; you came here asking for help, and you have no idea what your interlocutor knows. It didn't claim to be an answer just "related". – msw Aug 15 '13 at 03:44
  • 2
    If you have any specific, reasonable questions about something in that answer, leave a comment there and I'll probably be happy to clarify. As @msw said, no need to be rude; considering the fact that my answer there currently sits at +56/-0 votes, the community obviously thinks it is as a relevant answer to that question, and also as pointed out I only mentioned it as being "related", mainly because both questions deal with the issue of Linux's file system layer. I don't really play the rep game, but somehow I don't think I got to a network-wide currently 17k+ rep by writing incorrect answers. – user Aug 15 '13 at 07:27

3 Answers3

12

There is a component in the kernel (called the virtual file system, or VFS for short) that provides a generic interface to all filesystems. It understands things like file types (regular files, directories, symbolic links, …), metadata (times, permissions, …) and file contents.

Each Linux process lives in a namespace that specifies where filesystems are mounted. Often all the processes live in the same namespace; namespaces are mainly intended to support virtualization. A namespace is essentially a collection of paths, with an internal filesystem reference associated with each path. Mounting and unmounting consists of changing that namespace.

When the process access a file, the VFS component parses the path based on the process's namespace and current directory and determines under which mount point the file is located. The VFS then dispatches the file-related command to the appropriate filesystem driver based on the internal filesystem reference associated with the mount point.

It's the job of the filesystem driver to translate the command into data storage or retrieval. Each filesystem type. Most filesystem drivers don't interact directly with hardware but only with other drivers. A driver for a disk-backed filesystem (ext4, btrfs, vfat, …) translates the command into block storage operations (read and write sectors from a partition or other block device). A driver for a network-backed filesystem (nfs, cifs, …) translates the command into communication over a network channel. A driver for an internal kernel filesystem (proc, sysfs, …) works on its own. The FUSE filesystem driver passes the command on to a userland process.

Gilles 'SO- stop being evil'
  • 829,060
6

For each filesystem there is a driver written with an API that Linux's VFS can invoke when it comes across an object stored on a filesystem of that type. This allows transparency across the entire directory hierarchy regarding Linux's file- and filesystem-oriented system calls (as much as possible, e.g. no permissions on VFAT, therefore chown(2) will fail).

Ignacio Vazquez-Abrams
  • 45,725
  • So there exists one primary device driver per filesystem, because, i.e., a filesystem itself can be thought of as just an abstraction specification, not necessarily what will access storage mediums as a block device carrying bits, etc., like privileged architectural code would(e.g., x86, C, Assembly, etc.). – Megaloma Aug 14 '13 at 21:51
  • Exactly. This allows you to, e.g. put a ext3 filesystem on a CD or within a file. – Ignacio Vazquez-Abrams Aug 14 '13 at 21:51
  • But from a different kernel, i.e. Windows, the kernel or OS doesn't have the capability to access non-FAT or NTFS filesystems, so any ext3 filesystem stored on a CD-Rom can't be mounted as an accessible drive. – Megaloma Aug 14 '13 at 21:54
  • 1
    The problem is actually bigger than that. Even with a ext3 driver, Windows assumes that optical media can only have ISO9660 or UDF filesystems; you can create a NTFS CD under Linux, but Windows still won't be able to read it. – Ignacio Vazquez-Abrams Aug 14 '13 at 22:09
  • And Linux will access non-ISO or UDF filesystems? I never knew that about Windows. Even Windows 8? – Megaloma Aug 14 '13 at 22:10
  • 1
    Linux can access any filesystem anywhere (assuming appropriate drivers), due to the (apparently) infinite nesting capability of its VFS. I haven't tried it under Windows 8, but I wouldn't be surprised if it still didn't work. – Ignacio Vazquez-Abrams Aug 14 '13 at 22:12
0

Every type FileSystem is a driver in kernel. FileSystem driver call disk driver to access block device.

Edward Shen
  • 878
  • VFS module call filesystem driver,call disk driver to hardware. – Edward Shen Aug 15 '13 at 01:42
  • File system content doesn't necessarily live on block devices. Consider network file systems, procfs, sysfs, possibly tmpfs/shmfs, ... – user Aug 15 '13 at 07:32