I have noticed a few partitions which are rather empty and doesn't get used up frequently. For example, the /cache partition and the /dev partition.
Not entirely sure whether the phone would use up those partitions as it seems empty majority of the time. So is it possible to create something which inserts a swap file into those partitions and act as a reserve ram?
Not entirely sure whether a huge amount of reads and writes on those partitions would somehow damage the eMMC chip.
Related
I've noticed that everywhere in the ROM threads people using apps2sd seem to partition their SD-cards with ext3. I have a bit of experience with Linux filesystems and I am quite baffled by the choice, especially for flash media, where wear is a very real concern.
Some of the reasons I've seen for people choosing ext3 over ext2 are just plain wrong. E.g. speed; people say that ext3 is faster because it does journaling as opposed to ext2 that doesn't. This is not true, journaling actually makes file operations slower because the journal needs to be updated for every single operation. Journaling makes filesystem recovery faster, because the journal will show exactly which operations did not complete successfully, but this is not very useful due to the relatively small sizes of the partitions and the fact that the phone doesn't crash that often.
Keeping the journal also increases wear on the SD-card as the journal is written to on every operation, and its very specific location means that the SD-card is worn at this location and may make it unusable sooner than normal use would.
So if anyone has some insights into why ext3 seems to be preferred over ext2, then I'd love to hear them, as this has been bothering me for some time.
- RK
Due to the fact that the SD is removable/un-mountable media and its tied in and recognized as "internal memory" by the system, journaling safeguards the data as it would during a system crash under Linux, not sure on the speed my self but the rest is true to the best of my knowledge, its always been the "preffered" format.
Sent from LeeDrOiD loaded HTC Desire using Tapatalk
Moved to Q&A. Please don't post question threads in Development.
Journaling does not actually keep your data safer, it only speeds up the recovery time, as the recovery operation does not have to walk through the entire inode structure to confirm that the file system is consistent. As I said, the size and number of files on the ext-partition make a journal pretty pointless, especially since random access times are very low on flash media, which makes the recovery walk even faster.
So I still don't agree with the choice of ext3 over ext2.
PS. Thanks for correcting my mistake, rofld.
I tried searching for an answer to this question on Google but I haven't been able to find an exact answer. At this moment, I'd like to ask the folks at XDA Community to see what the actual differences are. Listing out Pros and Cons would be much appreciated.
Thank you in advance!!
I hope this helps
I think if you visit this thread you'll get a good understanding, please remember to thank AproSamurai for taking the time to put it together.
http://forum.xda-developers.com/showthread.php?t=1387334
Question Answered
Thanks!
So, I have gathered the following source from the link provided above.
What is a partition?
A partition is an area of allocated space, a division of the whole overall area of space. In this case our partitions on the Epic 4G are /System, /Data, as well as /Cache. All with set permanent sizes.
What is a partition map?
A partition map is the configuration of our partitions, it's what in a vagueness sets our required sizes for the divisions of our nand also known as flash memory. A partition or partition map should not be confused with a file system. An example would be BML and MTD.
What is a file system?
A file system resides on the partition map and governs the data being read/wrote/moved/etc by the Operating System, in this case Android. Changing a file system is less complex than an overall change in partition mapping. They again, are not the same thing.
What is MTD?
MTD is an Open Source Partition map. It allows those who are using it control over how their partitions are sized and how much space is allocated here and how much space is taken away from there. Currently on MTD we have 689 megabytes of space allocated to our /data partition allowing more to be downloaded from the market as an example. MTD as a partition config has YAFFS2 as a file system residing on it governing how data is transferred and the speed of which it is done. EXT2 through 4 aren't possible on the MTD platform, just as YAFFS2 may not be possible on the BML proprietary platform.
What is BML?
BML like MTD is a partition map, however it is proprietary in nature, Close Source if you will. The size for /System /Data /Cache is set and permanent and makes opening up space more of a task for Developers. Stock the Epic 4G comes on BML, and is running RFS as it's file system, once rooted you can leave RFS for EXT4 (Journaled or Un-Journaled) as long as the kernel you use allows for EXT4. But in the end, changing a file system on BML does not lessen or enhance the control you have over your partitions.
[Source/Credit: AproSamurai]
http://forum.xda-developers.com/showthread.php?t=1387334
It sounds like you've got it now! That's a pretty good writeup too, even if it is basically a repost.
Goodroid said:
Thanks!
Click to expand...
Click to collapse
You're welcome
Just thinking out loud....
I don't know if the ICS leak flashes change the partition table, but the way my phone is set up, there's 11 partitions:
p1: /efs
p2: /system
p3: /cache
p4: The "Internal SD"
p5: A mere 2MB. Mostly blank (long stretches of 00 or FF), except for <1KB of... something. Nothing jumps out at me in the hexdump. Could just be leftover garbage from Gingerbread.
p6: /data
p7: 16MB. Definitely something important here. Strings present suggest it's related to, if not part of, the bootloader, or perhaps download mode.
p8: 5MB: Looks like an Android bootimg. Recovery?
p9: 8MB: Pretty sure this is where the Linux kernel and rootfs for the actual system resides.
p10: 8MB: Completely blank.
p11: 500MB. An ext4 filesystem containing only the Asphalt 6 video and screenshots that you'd find on the "Internal SD" of a freshly Odin'd Glide.
I wonder if p5 actually serves a purpose; if not, we could theoretically merge it, p4, and p6 into one gigantic /data partition. That may be a bit more useful for those running with large microSD cards.
Things we need to look at:
One, bootloader. Does it look for things at static offsets? Does it read the partition table?
Two, recovery. I'm guessing CWMR will read the partition table, but is it expecting certain partitions to contain certain things?
In both cases, it shouldn't be anything we can't work around by filling out partition numbers or stretches of NAND with blank partitions. But we'll need to know what the offsets need to be.
Just putting the thought out there.
PIT & GPT, custom PIT
Actually the last PIT partition contains GPT data, and what we've seen inside the booted system comes out of GPT. But there is unallocated ~11Mb (according to GPT) before the first partition, and the PIT contains info about that!
cross-ref my thread: [Q] mmcblk0 Partiton table type (sgh-i927)
For now I'm looking a way of crafting my custom PIT-file, did you see any info about that?
My DInc NAND went bad, it became read-only and could not be written to. This is the 8GB NAND that houses /data, /cache, and /emmc partitions.
Tiny came out with a nice little patch for me, to patch custom ROMs in order to use partitions on the physical SD card as /data and /cache. That worked well for awhile, though with an occasional glitch where I'd get random factory resets. Anyway, I don't use the DInc anymore, thinking to fix it with a new motherboard from a cracked screen phone or something and selling it. Probably won't hardly go for anything, but it's not doing me much good sitting around. With that plan in mind, I decided to pull the bad NAND chip just to see how hard that is. Got a new SMD rework station and figured it's something I could goof off with on a boring Saturday morning. It came out without much fuss.
Anyhow, now the phone won't boot CM11 with the NAND chip missing. The phone does try to boot because /boot and /system are on a different NAND chip, but now it's not seeing /data or /cache on the physical SD card, at least that's my guess. I do plan to replace the motherboard, but mainly just curious why it no longer works. Is because of partition order? Because I lost 3 bad read-only partitions, the partition count is now off?
I knew it was possible I'd end up killing my DInc by pulling the bad NAND and I'm not too broken up about it. Mainly just curious why it no longer works, and kind of wondering if it's possible to fix.
Figured out some stuff.
With bad NAND chip removed, MicroSD takes its place as /dev/block/mmcblk0.
In a way, this is kind of good. If I make 3 partitions on MicroSD, I no longer need to use Tiny's patch or a custom recovery to map everything to mmcblk1. I can now use the same TWRP recovery everyone else uses and it recognizes mmcblk0p1 as /data, mmcblk0p2 as /cache, and mmcblk0p3 as /emmc.
Even CM11 and Evervolve 4.4.4 work without any patch and recognizes mmcblk0p1 as /data, mmcblk0p2 as /cache.
However, neither ROM maps mmcblk0p3 to anything. /sdcard, /emmc, /storage/sdcard0, /storage/sdcard1, none of those are mapped to mmcblk0p3.
UPDATE: Figured it out. Had to change /devices/platform/msm_sdcc.3/mmc_host/mmc2 to /devices/platform/msm_sdcc.2/mmc_host/mmc1 in fstab.inc.
just wondering, how are you determining that you have a bad nand chip? are you running any sort of test that can tell you definitely?
I have 3 dincs, 2 that I bought refurbished and used on eBay that seem to have been repaired(the water damage sticker has been tripped). I always assumed that the HTC Dinc was just a weak, limited and terrible phone due to bad 1st generation design. My phones had been prone to rebooting and errors due to the small system app partition. But they have worked reasonably well for me the last 3-4 years.
I upgraded all 3 to the latest evervolv 4.0 version with TWRP 2.6.3 and 2 of the 3 seem to have taken the upgrade well. have the 3rd one constantly reboots when trying to access anything via the play store. The internal 8 gig EMMC card had disappeared from it and also at times, the wifi controller disappears. I down graded it all the way back to Tiny 5-16(which it had run for the last 2 years) and it stabilized for the most part with the EMMC being seen again. Do you think the missing EMMC partition is a sure indicator that the memory on the phone is bad?
Here is the full thread:
http://forum.xda-developers.com/showthread.php?t=2175346
But long story short, I couldn't write to the eMMC chip at all. Not only my /emmc partition was read-only like some people had happen and could fix with fsck_msdos, but my entire eMMC chip, which means /data, /cache, and /emmc were read-only. RUU couldn't fix it, fsck couldn't fix it, and even attempting to remove and rebuild partitions using parted couldn't fix it.
I'm not sure if losing the /emmc partition by itself means the chip is bad. The chip also has the /data and /cache partitions. I'd think if either of those go offline, all your apps will start to FC. Although you did say it constantly reboots, and I think that's possible when /data and /cache go offline. I think mine actually did reboot an awful lot on its own before the eMMC chip went completely bad. You might try running e2fsck -c to check for bad blocks.
Some time ago, I stupidly formatted several file systems with a different type to see if that improves anything. I thought I got everything back to the correct type but now problems are cropping up again.
I'd like to check, but, I can't find a list with 'good' types for the different partitions.
Generally,
ext4 on your /system, /boot, /cache, and /data
exFAT or FAT32(vFAT) on your internal and external SD cards.
There are other types of file systems like F2FS that are not widely supported; just remember, it is your kernel that dictates the file systems you can run.