因為怕之後討論區文章可能會消失，所以先把全文備份過來...。
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.
IV. The System Partition
The partition mounted as /system is automatically mounted as read only. It's like this because, even with root (the unlocked ability to make changes to the partition mounted as /system) it's dangerous to make changes there if you do not know what you are doing. When you flash a ROM from recovery, it wipes that partition, and writes new contents to it. Recovery scripts, however, are smart enough to mount this partition in rw mode. If you are going to make changes to /system while booted up in Android, you must have /system mounted as rw. Otherwise, you will just get permission errors even thought you have root level permissions.
To do this, you must remount the partition under /system as rw. There are many ways of doing this. All of them are system-wide. What that means is, if you use an app to remount /system as rw, the entire system and any other app will see it such until you reboot the phone or remount it as ro. Root explorer, for example, has an option in the top right corner to mount whatever file system you are currently browsing as either rw or ro depending on what it's currently mounted as. Basically, it toggles between rw and ro. There is also an app in the marketplace called "Mount /system (rw /ro)", which will do that as well if you don't have root explorer. Let's look at it in a little more detail, though.
Should you want to remount the partition mounted under /system as rw using the command line from a terminal emulator, you would run this:
su mount -o remount,rw -t yaffs2 /dev/block/mtdblock4 /system
The "su" command is how you get root level permissions at the command line. You cannot change how a partition is mounted without it. Let's break down the second command:
- mount is the generic command used to view or modify currently mounted partitions or any media for that matter.
- -o is the option used to specify certain special mount options.
- a comma separated list following -o are the options you want to specify for mounting.
- remount means that the file system you are mounting is already mounted, and you want to specify some other options. You would leave this out if the filesystem was not mounted yet. As /system has to be mounted by virtue of the fact that you're using the system, you must specify the option to remount.
- rw means that you want /system to be mounted in read/write mode. By default, it is read-only, as previously explained.
- -t yaffs2 is the filesystem type of the partition. It's not that important for this explanation. Just understand that a partition must be formatted with a particular file system, which basically means how files are stored. Each operating system has the ability to understand certain file system types. More on this later.
- /dev/block/mtdblock4 is the logical location of the partition itself under /dev as previously explained. Should you want to mount a different partition, you would replace this line with it.
- /system is the location under / where the files belonging to the mtdblock4 partition will be made accessible. In the case of a remount, these last two strings should not change from how it is currently mounted. For example, if /system was mounted as /asdfasdf (just an example), you should not use remount to then mount it as /system. You'd stick with /asdfasdf. Just a point to remember; it will always be /system in this case. This is not the case if you’re mounting something for your own use, but changing the mount point of /system would be detrimental.
Once the above is done, a user can then make changes to /system, but only as the root user, of course. This requires using the terminal emulator after having typed "su" OR using an app that can run as the root user and browse all partitions. An example is Root Explorer.
Once the user is done making changes, /system should be remounted in ro mode, again, to avoid making unwanted changed. It's the safe thing to do. Rebooting will take care of it, but it can be done much quicker by reverting the change manually. Root explorer has the toggle, as does the other mentioned app. To do it from the terminal emulator, type:
su mount -o remount,ro -t yaffs2 /dev/block/mtdblock4 /system
The only difference between the two commands is that rw changed to ro. That's it.
V. Current Mounts
If you want to see how the system is currently using various partitions, you can run the mount command from the terminal emulator by itself, with no arguments or options. It will list several things including the partition itself, the mountpoint for said partition, and options used while mounting it (such as rw or ro). If you are interested in only a particular partition, run:
mount|grep /whateverpartition
where whateverpartition is the partition you want to see. For example, to see how /system is currently mounted:
mount|grep /system
You will see something like:
/dev/block/mtdblock4 /system yaffs2 ro 0 0
All of that information should look familiar now. The 0 0 at the end are other options that you don’t need to be concerned with outside or real Linux administration.
Having an understanding of how this works will help you determine ways of saving space and making the most of your available storage. The three major partitions are /data, /system, and /cache. A majority of your 1 GB of internal storage is used by these. The partitions sizes are set when the partitions are created. By default, this is how they are partitioned:
/system – 350 MB
/data – 430 MB
/cache – 160 MB
As you can see, you only have 430 MB for apps and data. That’s less than half of the advertised space. There are numerous apps on the market that will display the free space available on each partition, but it can be done from the command line as well by typing this:
df -h
That will show all mounted partitions, how big they are, and how much free space you have. You can check the same for just one partition by doing something like:
df -h /system
You can, of course, replace /system with whatever partition you want to see. You will probably notice that both /system and /cache have a lot of free space. As it turns out, most of that free space rarely gets used, and cannot be used by you for apps, at all. It’s wasted space. Cache, of course, will show mostly free space, but it’s necessary for things like OTAs, which will download to that directory. It does need to be somewhat large, but not *that* big. In any case, there are ways of having more space available than just 430 MB. The best place to start is a2sd.
VI. A2sd, Apps2sd, and File System Types
With all of this knowledge in mind, you can probably get a better understanding of how something like a2sd works. A2sd is a system devised to move all installed applications to the sdcard. This is by no means the same thing as the built-in froyo apps2sd.
With Froyo apps2sd:
- The developer of a certain app specify that it is allowed to be moved to the sdcard.
- Even when it is, if the app has widgets, those widgets will not be available once the app is on the sdcard. Why? Because the sdcard is unmounted once the phone is connected to a computer as a disk drive. If widgets belonging to such an app were on the homescreen at that time, they would stop working. Google designed Android to avoid such a case by just making those widgets unavailable.
- Only a part of the app is moved, not the entire thing. If you've ever looked at at an app that has been moved to the sdcard in manage applications, you will see that it still is taking up space on internal storage (in /data). The reason this happens goes back to file system types.
Linux based systems have a certain number of file system types that it can use. Windows has its own as well. The sdcard needs to be formatted in a file system that is basically universal. This means that no matter what kind of computer you plug the phone into, plus the phone itself, you need to be able to view/modify the contents of the card. That file system is fat32. Both Linux and Windows can view/modify said contents. BUT, Linux (Android) can't execute anything off of a fat32 partition. Its use of it is somewhat limited. That being said, Android cannot move an entire app to the sdcard in its stock condition, as it would be moving it to a fat32 file system, where it would not be able to execute it.
A2sd has none of these issues, and gets around them in a fairly creative way. The sdcard, in stock state, has one partition, which is this fat32 partition. You still need a majority of the card to have this fat32 partition for the purpose of using it *normally*, but a2sd must use a partition type that is native to Linux. So, the first thing you must do to use a2sd is partition the card into two separate partitions. This can be done in recovery. Once it is done partitioning, it formats the two partitions using a particular file system. The bigger partition, which the user will continue to see as /sdcard and keep all of there data, remains fat32. The smaller partition (usually made between 512 MB and 1 GB) is formatted in the ext3 file system. This ext3 file system type is native to Linux. What does this mean? It means that Android can use that partition on the sdcard the exact same way it could internal storage.
Now, You might be asking yourself at this point, doesn't Android have to mount this new ext3 partition just like it does internal storage partitions and the normal fat32 sdcard partition? Why, yes it does. It mounts the partition just like any other partition, but it makes the mount point /system/sd. Once you've created the ext3 partition, you can browse /system/sd. It will look just like a directory in internal storage, but since it's a mountpoint, when you view it, you're looking on the sdcard, just in the smaller, ext3 partition. Having done this, you've basically fooled the system into thinking you have more internal storage. The issue is that Android will look for apps in two main places - /data/app and /system/app. if you just stuck an apk (Android application) in /system/sd, Android system would never find it, as it will never look there. For those interested in seeing how the sdcard partitions are mounted, run these two commands:
mount|grep /sdcard mount|grep /system/sd
The output for /system/sd, for example, looks like:
/dev/block/mmcblk0p2 on /system/sd type ext3 (rw,noatime,nodiratime,errors=continue,data=writeb ack)
Both of those commands, though, will show how the fat32 sdcard partition is mounted (/mnt/sdcard) and how the ext3 sdcard partition is mounted (/system/sd). As you can see, mmcblk0p2 is the ext partition, while the majority of the card (the fat32 partition) is mmcblk0p1. Another quick important point is that /system/sd is mounted as rw so that you can make changes. Remember this - if a partition is mounted as ro (/system) but a directory under it is used as a mountpoint (/system/sd) you will still be able to write to whatever is mounted under that second directory as long as the partition is mounted as rw. That being said, you can leave /system mounted as ro, and still always make changes to /system/sd.
Anyway, a2sd is how you use this new ext3 partition. The first thing a2sd does is move all applications from /data/app and /data/app-secure to /system/sd/app and /system/sd/app-secure. Remember that with *just* this step, the system would not see apps anymore. At this point, a2sd makes use of something called a symlink. Think of a symlink as a shortcut in Windows. When you create file in a particular folder, then make a shortcut to that file from a different folder, it exists in the first folder, but is accessible from the second folder. The same holds true for folders. A symlink is basically the same thing. So, a2sd removes the /data/app and /data/app-secure directories, then creates symlinks (shortcuts) called /data/app and /data/app-secure that point to directories in /system/sd for apps. This means that the system will continue to look in /data/app and /data/app-secure for apps, but will be directed to /system/sd. Basically, the system doesn't care where files actually are. It only cares that it can find them where it knows to look.
A2sd can also be used to move dalvik cache to the sdcard. It does this in exactly the same manner as moving apps. Dalvik cache is normally stored in /data/dalvik-cache. A2sd creates a directory in /system/sd for dalvik-cache, then creates a /data/dalvik-cache symlink that points to the real location.
As dalvik cache is stored in /data by default, it takes up your usable storage, needlessly. That is why it can be moved to the sdcard ext3 partition. If you choose to, though, it can also be moved to the /cache partition. /cache is normally just unused space on internal storage that is way bigger than it needs to be. Thus, dalvik cache can be moved there instead, too. The idea is the same, but it doesn't use symlinks. It does some creative work with the mount command to make the system look there for it. How it actually works is out of the scope of this information.
VII. Other Space Saving Options
Some people do not want to use a2sd, as they do not have good enough sdcards and are not interested in buying a new one. A2sd will not work well with a slower card, such as the one that comes stock with the Evo. However, it is possible to reclaim some of the unusable internal storage. If you remember, /data, /system, and /cache make up a majority of your internal storage. They can be resized with this mod.
That process is only recommended for advanced users and only under certain circumstances. Should you decide to move all apps and app data to the sdcard using a2sd, there is no purpose in resizing the partitions. Very little else goes in /data. Basically, either use a2sd to its fullest extent or resize partitions. Don’t do both.
沒有留言:
張貼留言