When a flash drive/hard drive is connected to a system, it should be mounted. What exactly happens during the mounting process? How does the system/kernel keep track of content that is present in the flash drive?
First off, unless you have software running to do this, it actually won't be mounted automatically. That behavior is entirely handled from userspace, not in the kernel, which is rather important as mounting automatically is a nightmare for security (it is possible to crash or at least DoS most systems with a carefully crafted filesystem image).
Now, as to what's actually happening, her'es the general sequence on Linux using the standard combination of udev and udisks to trigger the automount:
- The device is physically connected, and gets enumerated by the kernel. The kernel recognizes it as a block device of some sort, sets up the appropriate drivers to expose this interface to userspace, and then fires off a uevent to tell whatever is listening in userspace that new hardware has been connected.
- The kernel scans the device for partitions.
- Udev sees this uevent, and sets up the various device nodes and links in
/devfor the device. It then scans the device and it's partitions to see what filesystems are present and where, and stores this data where other programs can query it.
- Udisks sees the uevent from the kernel, verifies that udev is done setting things up, and then checks if the scanning done by udev in step 3 found any filesystems. If it did, and udisks is configured to auto-mount newly connected filesystems, it issues a mount request to the kernel for each filesystem.
- The kernel mounts the filesystem by doing the following internally (greatly simplified):
- It first checks that it has an appropriate driver for the filesystem type, and if not, tries to load one.
- The filesystem driver parses any required metadata out of the filesystem superblock (this is where all the metadata about the filesystem itself is stored).
- A in-memory copy of the super block is created and populated with the data provided by the filesystem driver and the mount command. This data structure is what the kernel uses to refer to the filesystem internally. Any other internal references to the filesystem inside the kernel ultimately point back to this.
- The kernel then updates it's internal mount table with a reference to this in-memory super-block.
Now, as to how the kernel 'keeps track of the content', that's a whole lot more complicated to explain properly. In short though, it doesn't. Whenever you go to try and access a file on the device, the kernel looks it up from the root of the filesystem. There is a cache involved to speed this up, but it's not really critical to anything but performance.
It keeps track of the content of the flash drive by storing it in the flash drive.
It also has a mount table (in the kernel).
It knows that
/dev/disk/by-label/home (a link to a real device) is mounted on
/home. It knows that the usb-flash is mounted on
/media/my-flash When you change dir to these directories it traverses onto the other device.
df -h to view the current mount state.
Modern Linux graphical interfaces such as GNOME, mount filesystems by sending requests to the
udisks background process ("service"). They tend to do this automatically when you plug in a drive. It can be hard to find how to stop them doing so, to let you test the effect of commands like
mount for yourself. One simple way to avoid it, is to log in on a text console. (For some information about logging in on a text console, see here)
There is also a command you can use to send requests to
udisks. The current version of this command is called
When you plug in a usb flash drive, (usually) the usb storage driver "binds" to it, and creates a block device.[*] On Linux: see
lsblk (list block devices).
Similarly, when you
mount the block device, you are binding some filesystem software to it. There is different software for different filesystem formats. E.g. the FAT32 filesystem is often used on flash drives; Linux calls this filesystem type
vfat. When you run
mount, you must include two parameters: the device, and the name of a directory to mount the filesystem on. When you access that directory name (e.g.
ls /mnt), you will see the mounted filesystem in place of the original directory.
If you run
mount with no parameters, it will list your mounted filesystems. On Linux, however,
man mount will tell you it is better to use
findmnt to list filesystems.
findmnt has nice output that helps organize the many virtual filesystems you have mounted on Linux (although it does not sort them alphabetically like
df -h also has nice output, as it excludes many of the virtual filesystems Linux has, and shows available space on each filesystem. (Strictly speaking, some complex Linux filesystem setups may have a more complex handling of available space than shown, e.g. they may require less space for file data by compressing it).
All the files you can access are stored on some mounted filesystem. Notice that
/ shows up in the list of mounted filesystems.
/ is the "root" directory.
/ is the first part of the full "path" (location) of any file. (Note: the full path of a file is described as the "absolute" path).
There is one special thing about the root filesystem:
umount (un-mount) cannot work on it. The root filesystem is always considered to be in use.
The system shutdown sequence will re-mount the root filesystem as read-only (
mount / -o remount,ro). Remounting a filesystem read-only, is a way to request that it write back any changed files e.g. to the block device that is your hard disk, and prepare itself for a clean shutdown. In this sense it serves the same purpose as unmounting.
Some low-level Linux software can swap the root filesystem with another mounted filesystem; this is called
pivot_root. Then the old root filesystem can be unmounted. Doing this requires a number of specific conditions which I will not attempt to explain here. The feature was created to serve the boot process of general-purpose Linux distributions, where an initial ram-based filesystem (initramfs) mounts and then pivots to the real root filesystem. There is an explanation for why they do this, here.
[*] On Linux, the first device using the
sd driver is allocated the name
sda, and so on.
usb storage devices accept some form of SCSI. So the usb storage driver provides a scsi device; the
sd (SCSI disk) driver binds to the scsi device and provides a block device.
sd is used for many types of block devices. Which are not necessarily physically disks, and also the hardware may use different commands which have to be translated from SCSI. Computers are weird; the reason for such patterns may depend on many historical details which are not necessarily relevant.