1Here's how mount actually works: 2 3The mount comand calls the mount system call, which has five arguments you 4can see on the "man 2 mount" page: 5 6 int mount(const char *source, const char *target, const char *filesystemtype, 7 unsigned long mountflags, const void *data); 8 9The command "mount -t ext2 /dev/sda1 /path/to/mntpoint -o ro,noatime", 10parses its command line arguments to feed them into those five system call 11arguments. In this example, the source is "/dev/sda1", the target is 12"/path/to/mountpoint", and the filesystemtype is "ext2". 13 14The other two syscall arguments (mountflags and data) come from the 15"-o option,option,option" argument. The mountflags argument goes to the VFS 16(explained below), and the data argument is passed to the filesystem driver. 17 18The mount command's options string is a list of comma separated values. If 19there's more than one -o argument on the mount command line, they get glued 20together (in order) with a comma. The mount command also checks the file 21/etc/fstab for default options, and the options you specify on the command 22line get appended to those defaults (if any). Most other command line mount 23flags are just synonyms for adding option flags (for example 24"mount -o remount -w" is equivalent to "mount -o remount,rw"). Behind the 25scenes they all get appended to the -o string and fed to a common parser. 26 27VFS stands for "Virtual File System" and is the common infrastructure shared 28by different filesystems. It handles common things like making the filesystem 29read only. The mount command assembles an option string to supply to the "data" 30argument of the option syscall, but first it parses it for VFS options 31(ro,noexec,nodev,nosuid,noatime...) each of which corresponds to a flag 32from #include <sys/mount.h>. The mount command removes those options from the 33sting and sets the corresponding bit in mountflags, then the remaining options 34(if any) form the data argument for the filesystem driver. 35 36A few quick implementation details: the mountflag MS_SILENCE gets set by 37default even if there's nothing in /etc/fstab. Some actions (such as --bind 38and --move mounts, I.E. -o bind and -o move) are just VFS actions and don't 39require any specific filesystem at all. The "-o remount" flag requires looking 40up the filesystem in /proc/mounts and reassembling the full option string 41because you don't _just_ pass in the changed flags but have to reassemble 42the complete new filesystem state to give the system call. Some of the options 43in /etc/fstab are for the mount command (such as "user" which only does 44anything if the mount command has the suid bit set) and don't get passed 45through to the system call. 46 47When mounting a new filesystem, the "filesystem" argument to the mount system 48call specifies which filesystem driver to use. All the loaded drivers are 49listed in /proc/filesystems, but calling mount can also trigger a module load 50request to add another. A filesystem driver is responsible for putting files 51and subdirectories under the mount point: any time you open, close, read, 52write, truncate, list the contents of a directory, move, or delete a file, 53you're talking to a filesystem driver to do it. (Or when you call 54ioctl(), stat(), statvfs(), utime()...) 55 56Different drivers implement different filesystems, which have four categories: 57 581) Block device backed filesystems, such as ext2 and vfat. 59 60This kind of filesystem driver acts as a lens to look at a block device 61through. The source argument for block backed filesystems is a path to a 62block device, such as "/dev/hda1", which stores the contents of the 63filesystem in a fixed block of sequential storage, and there's a seperate 64driver providing that block device. 65 66Block backed filesystems are the "conventional" filesystem type most people 67think of when they mount things. The name means that the "backing store" 68(where the data lives when the system is switched off) is on a block device. 69 702) Server backed filesystems, such as cifs/samba or fuse. 71 72These drivers convert filesystem operations into a sequential stream of 73bytes, which it can send through a pipe to talk to a program. The filesystem 74server could be a local Filesystem in Userspace daemon (connected to a local 75process through a pipe filehandle), behind a network socket (CIFS and v9fs), 76behind a char device (/dev/ttyS0), and so on. The common attribute is there's 77some program on the other end sending and receiving a sequential bytestream. 78The backing store is a server somewhere, and the filesystem driver is talking 79to a process that reads and writes data in some known protocol. 80 81The source argument for these filesystems indicates where the filesystem lives. It's often in a URL-like format for network filesystems, but it's really just a blob of data that the filesystem driver understands. 82 83A lot of server backed filesystems want to open their own connection so they 84don't have to pass their data through a persistent local userspace process, 85not really for performance reasons but because in low memory situations a 86chicken-and-egg situation can develop where all the process's pages have 87been swapped out but the filesystem needs to write data to its backing 88store in order to free up memory so it can swap the process's pages back in. 89If this mechanism is providing the root filesystem, this can deadlock and 90freeze the system solid. So while you _can_ pass some of them a filehandle, 91more often than not you don't. 92 93These are also known as "pipe backed" filesystems (or "network filesystems" 94because that's a common case, although a network doesn't need to be inolved). 95Conceptually they're char device backed filesystems (analogus to the block 96device backed ones), but you don't commonly specify a character device in 97/dev when mounting them because you're talking to a specific server process, 98not a whole machine. 99 1003) Ram backed filesystems, such as ramfs and tmpfs. 101 102These are very simple filesystems that don't implement a backing store. Data 103written to these gets stored in the disk cache, and the driver ignores requests 104to flush it to backing store (reporting all the pages as pinned and 105unfreeable). 106 107These drivers essentially mount the VFS's page/dentry cache as if it was a 108filesystem. (Page cache stores file contents, dentry cache stores directory 109entries.) They grow and shrink dynamically, as needed: when you write files 110into them they allocate more memory to store it, and when you delete files 111the memory is freed. 112 113There's a simple one (ramfs) that does only that, and a more complex one (tmpfs) 114which adds a size limitation (by default 50%, but it's adjustable as a mount 115option) so the system doesn't run out of memory and lock up if you 116"cat /dev/zero > file", and can also report how much space is remaining 117when asked (ramfs always says 0 bytes free). The other thing tmpfs does 118is write its data out to swap space (like processes do) when the system 119is under memory proessure. 120 121Note that "ramdisk" is not the same as "ramfs". The ramdisk driver uses a 122chunk of memory to implement a block device, and then you can format that 123block device and mount it with a block device backed filesystem driver. 124(This is the same "two device drivers" approach you always have with block 125backed filesystems: one driver provides /dev/ram0 and the second driver mounts 126it as vfat.) Ram disks are significantly less efficient than ramfs, 127allocating a fixed amount of memory up front for the block device instead of 128dynamically resizing itself as files are written into an deleted from the 129page and dentry caches the way ramfs does. 130 131Note: initramfs cpio, tmpfs as rootfs. 132 1334) Synthetic filesystems, such as proc, sysfs, devpts... 134 135These filesystems don't have any backing store either, because they don't 136store arbitrary data the way the first three types of filesystems do. 137 138Instead they present artificial contents, which can represent processes or 139hardware or anything the driver writer wants them to show. Listing or reading 140from these files calls a driver function that produces whatever output it's 141programmed to, and writing to these files submits data to the driver which 142can do anything it wants with it. 143 144Synthetic ilesystems are often implemented to provide monitoring and control 145knobs for parts of the operating system. It's an alternative to adding more 146system calls (or ioctl, sysctl, etc), and provides a more human friendly user 147interface which programs can use but which users can also interact with 148directly from the command line via "cat" and redirecting the output of 149"echo" into special files. 150 151 152Those are the four types of filesystems: backing store can be a fixed length 153block of storage, backing store can be some server the driver connects to, 154backing store can not exist and the files merely reside in the disk cache, 155or the filesystem driver can just make up its contents programmatically. 156 157And that's how filesystems get mounted, using the mount system call which has 158five arguments. The "filesystem" argument specifies the driver implementing 159one of those filesystems, and the "source" and "data" arguments get fed to 160that driver. The "target" and "mountflags" arguments get parsed (and handled) 161by the generic VFS infrastructure. (The filesystem driver can peek at the 162VFS data, but generally doesn't need to care. The VFS tells the filesystem 163what to do, in response to what userspace said to do.) 164