This thread is meant to be a supplement to novox77's thread on partitions and kernels, found here. This is strictly an informational thread, and does not include an actual guide for accomplishing anything. It will, however, provide some background on some of the inner workings of Android, hopefully. Read novox77's thread, first, before reading this information. Novox77 and I decided it would be better to make a separate thread for this, but Mod's, if you feel otherwise, please merge them. I. The Basics Every operating system has a way of viewing and manipulating the filesystem(s) available to it. In the case of Windows, you have designated drive letters which represent the physical drives or partitions on a drive. Under each drive, you have folders and files. Those folders and files are data on each one of those specific drives. It's all very concise and obvious as to what data exists on what drive. There *are* things you can do complicate this, but this is not a discussion about Windows. Android does not work anything like Windows, however, as it is a Linux based system. Linux/UNIX type systems have one top level file structure. The top level is called root, and is designated by /. There are no drive letters, and the files and folders under / are not necessarily all stored in the same physical location. Let me just take a very brief detour here. The top level file system is called root. When we say root in this case, we are not talking about the root user or root level permissions. When you root the phone, we're talking about have permissions to do things as the root user and make changes we couldn't otherwise do. The word root is used for different things. When you hear the word root used with filesystems, we mean the top level. From this point on, the root of the file system will just be referred to as /. There really isn't much under / by itself. It's generally a small partition. In order to use other partitions, Android must make these partitions available under /. There is a special directory called /dev. Under this directory, you will find logical representations of partitions and resources available to the system. These, on their own, are just device files. These files exist solely so that the system knows they exist. You cannot try to view anything in them. So, in order to use partitions found in /dev, the system must mount them under /. This means the system must take a physical or logical media where you have some data stored, and make it available. II. Mounting When the system (or the user) initiates this process of mounting, a directory (folder) must exist somewhere under / for the partition to be mounted to. It can be directly under / or in a nested directory under /. We call this a mountpoint. What it means is that an empty directory will be designated to show the contents (data) of a partition. So, we say that internal storage is partitioned with various partitions such as /boot, /system, /data, /cache, etc. What this really means is that these partitions are all a part of internal storage, but have been logically separated so that the system sees them as separate as different physical media (i.e. partitions), but are then all mounted (made accessible) in one logical location. If you browse files on /system, then browse file on /data, you're under the root filesystem in both cases, but are looking in two different actual locations. This type of thing is certainly not limited to partitions on internal storage. Any time you have a different physical media, it must be mounted under / just like any other partition. For example, you have a directory under / called /sdcard. That is a symlink (shortcut) to /mnt/sdcard, which is a mountpoint for the sdcard. More information on symlinks and how they work later. For now, just understand that it's basically a shortcut. Anyway, its partition can be found in /dev, as well, albeit in a different location. It is mounted under /mnt, accessible under /, all the same. The reason it's mounted under /mnt rather than / is because Linux based systems usually use /mnt for external device mounts. It doesn't have to, though. It could be mounted directly under / as /sdcard. It would still work. In any case, think of viewing the sdcard this way in the same manner that you would connect a usb flash drive to a Windows computer. When you do that, Windows sees the physical drive, then creates a letter drive for you to view it's contents. The principle is the same in that Android sees the physical media, but it mounts it in the same logical location (/) as all the other mountpoints. From a user's perspective, on Android, all the mountpoint directories look like they may as well be on the same media, even though they are not. On a Windows computer, when you are done with a flash drive, you have to tell it to safely eject the hardware. On Android (Linux), you have to do something similar, called unmount. If you do that to the sdcard, you will no longer be able to view /sdcard. Though you could create a directory under / called sdcard, it wouldn't have anything in it, and would be just a directory on internal storage until you remount the sdcard. Typically, the system mounts and unmounts partitions automatically when necessary. There are two very important conclusions made from the above: 1) The system mounts and unmounts partitions at boot and shutdown. If you pull the battery out while the system is running or use a poorly written app to reboot the phone, partitions are still mounted, and if the system is writing to them, you could easily corrupt something. Granted, sometimes this is necessary if the phone becomes unresponsive. It's more likely to be a problem if repeatedly done. 2) Ever wonder why you cannot access the sdcard while the phone is connected to a computer as a disk drive? It's because the computer is mounting the sdcard partition so that you can see it there. What does that mean? It means Windows, Linux, etc. (whatever OS you have on your computer) has *direct* access to that physical media. No two operating systems can have direct control over physical media at the same time. It would result in massive data corruption. You may be wondering how it's possible to share drives or partitions in the networking world. You can do so because the Computer that has the physical media is still the only host that can physically read and write to the media. Sharing of the data is done at a much higher level and is controlled by the operating system. III. Mount Options Linux based systems have a file called fstab. That file is a mapping of physical partitions and their mountpoints, along with options it needs to know when mounting said partitions. It uses this file to mount partitions at boot time. So, the fact that you don't have to mount /system, /boot, /data, etc. yourself is because the system does it for you. It uses options it's told to use, though. There are various options that can be specified, but it is out of the scope of this explanation. What is important, though, is the designation between read/write (rw) and read-only (ro). This option is specified at boot time for automatically mounted partitions. The partition mounted as /data is mounted as rw. It has to be, otherwise the system would be all but unusable. You wouldn't be able to install apps, change settings, etc. Do not confuse this with file permissions. That is a different discussion for a different time, but at least understand this - file and directories have certain permissions that allow the file owner, the group the file owner belongs to, and everyone else specific access to said file. Those permissions can be either the ability to read the file, write (modify) to the file, or execute it. The same goes for directories (though executing a directory doesn't make sense). The point is that a partition must be mounted as rw in order for write permissions to work. If you have permission to write to a file on a partition, but it is mounted as ro, it will not work.