What does it actually mean to mount a filesystem?
 

Yeah, I know, total n00b question. But in all seriousness, I cannot figure out what it means to mount a filesystem. I just don't understand how / can be mounted from a subset of root (/dev/[device]). What I mean is, how can /dev/(device) be mounted to / when you have to go through / to get to /dev? It makes no sense, and all the searches I've done for it just don't explain it in terms I can understand.

I would appreciate it if someone could provide a better explanation for me that is dumbed down to "idiot's terms," so to speak.
What I'm looking for is what exactly mounting means. I want to know what it means, what it does, and how it affects the system.

Also, sorry if this is the wrong forum. I thought about the newbie forum, but then it was like "MAKE SURE YOU'RE IN THE RIGHT FORUM" and I was like "uh..."

The "files" you see in /dev are not files, they're devices. You can access them through the filesystem for convenience sake, but they're not really there. If you were to mount your root drive in some other OS (say if you booted a live CD), the "dev" directory would be more-or-less empty. The same goes for most of what you see in /proc/. They're not real files, just a temporary reference to some memory location or device or kernel module that's being presented to you on the filesystem so that you can access it from "user space".

See, now this makes so much more sense. So the system initially mounts /dev/(device) to / so you can actually access all of your stuff, correct? Because if it didn't do that, you wouldn't physically be able to access any of your files or programs and linux would be unusable, no?

Before the root drive has been mounted, there is no filesystem, so there is no / or /dev or any of that. If you look at your grub config you'll see how your root device is being referenced before it's been mounted. Mine is "hd2,gpt1". After the drive has been mounted to /, device files are created for it and all of the other devices on the system (other drives, serial ports, etc.) in /dev/ so that they can be accessed from user space.

Hm...okay, so a little more confirmation: direct device references like /dev/sda (I know I used that before, but it's the best example :P) are unusable if they aren't mounted because it's just a direct reference to the memory address and you can't access any of the contents that way, correct? Or say, /media/cdrom (or whatever the cdrom location may be) would be utterly useless unless actually mounted to a certain location to access its filestructure, correct?

Most people come from windows where they know what C: is and what C:\ is.

Linux along with other OS's are not so hardware driven. One can manipulate storage to suite needs. It is more software driven.

There are two main issues with mount. First the system would have to know about some storage. Either as part of system or even network. It has to have that basics first. Then you can be allowed to use a mount command. That command could be behind the scenes on boot up or from your command line. You mount the filesystem with a command. In that command you used to have to be very specific about the file system and how it was to be mounted. Most newbies only use big name distro's that use a gui to mount or it automounts for you.

I suggest you look at the output of the manual pages for mount. Online here, http://linux.die.net/man/8/mount and from most distro's command line. Either a man mount command or in some cases mount --help command.

The order goes:

The machine loads the MBR on the boot drive, which is where grub is located
Grub loads its menu, and allows you to select which drive you want to boot from
Whatever drive you select is referenced in the way Grub uses, for example "hd2,gpt1" on my system. It doesn't use /dev/xxxx, because there's no such thing as /dev/ in this part of the boot process, there's not even a "/", there is no filesystem yet.
The next section is a bit fuzzy for me, but basically the root drive for the OS you select is mounted at /, then device files for every other device in the system are created in /dev/

As for your specific question:
That's partially correct. The device isn't completely unusable though, there are still many things you can do with an unmounted device. You can repartition it, you can format it, you can pull raw (very low level) data off of it, etc. In fact there are many things that can ONLY be done on the raw /dev/ entry for an unmounted device. The device won't be regularly accessible on your filesystem until it has been mounted though. The mounting process essentially reads the partition and filesystem information from the device, and then presents it to you in a "normal" fashion at whatever mount point you specify when you mount it.

Here's an excellent tutorial on the Linux file system.

http://tldp.org/LDP/intro-linux/html/sect_03_01.html

The key concept is this:

In *nix, everything is a file.

Things that are not files, such as devices, are represented by or treated as files, and the system talks to them by talking to (or through) the file.

So a device (/dev/sda1) is represented by a file in /dev. It gets "mounted" to a file in, say, /mnt or /media (say, /mnt/sda1), which makes it available to the system. The process of mounting links /mnt/sda1 to /dev/sda1. The system can then talk to /mnt/sda1, which is the interface or channel for talking to /dev/sda1 which in turn relays the information to the physical partition represented by /dev/sda1.

This is a clumsy and completely non-technical description which I am sure that others can improve, I know, but I hope it helps clarify the concept, at least as I understand it.

Thank you, you've all been a great help to me, and I feel like I understand the whole concept a lot better, now. It's tough having to learn all this stuff after being super familiar with Windows for 10 years, y'know?

There is a bit more to it that discussed.

When grub boots it loads the kernel, AND an initrd (initial read only filesystem) which a compressed archive of a tiny root system. The kernels built in init mounts a ram disk (empty), and the restores the archive to it. At this point the root device is the ram disk.

The init process now starts using facilities on the ramdisk - most are now using a service called "udev" which probes the existing hardware to identify what is in the system, and creates the inital /dev (which mounted as a "devfs" filesystem which is a filesystem representation of the device structures/drivers in the kernel). When drivers get loaded, they register with the devfs to create the "device files" used to access the device.

Note, all of this is still strictly memory resident. No disk based filesystems have been mounted.

The root device identified by the kernel parameters (taken from the grub boot - the parameter is "root=..." on the kernel specification) specifies the real, disk resident filesystem to use for /. This filesystem is usually identified by UUID (though it can be specified by device file name, or volume label). The problem with using the device file name is that the actual name created by udev depends on how/when udev identifies the device - a fast disk comes up before a slow one, so the fast one gets the sda name. But that doesn't mean sda<n> is the correct filesystem - It may be sdb.. if a disk gets replaced, things can get out of order. So UUID - this requires the udev service to retrieve the UUID for each partition it identifies.

When the memory resident init mounts the filesystem it uses /mnt of the ramdisk to mount it. The root filesystem is now known by the kernel.

A fancy system call ("pivot_root") is then used to exchange the ram disk root filesystem with that /mnt filesystem. At this point, the /mnt filesystem is the ramdisk, and / is now the disk resident filesystem. The /dev filesystem (the devfs memory resident thing) is mounted again as /dev, and the /mnt/dev dismounted, and the /mnt ramdisk dismounted. At this point the memory used by the ramdisk is reclaimed.

The kernel init isn't quite done yet - it then execs the init from /sbin/init so that the system can now complete its normal startup.

This slightly convoluted sequence makes the physical devices more independent of specific configuration - the root device could be on nearly anything, as long as that "anything" can be identified by the kernel.