[Q] CWM can't mount partitions

Search This thread
By:
Advanced…
G

giza1928

Member
May 18, 2014
8
0
Hi,

I have a problem with an Asus TF700T. I had Clockworkmod Recovery installed and tried using it to flash Cyanogenmod. The flash failed and since then, CWM can't mount /data, /system or any other partition from the internal flash memory. I've then used fastboot to flash a new version of CWM, but also the new version (6.0.4.7) can't mount the partitions.
I fear the partition table of /dev/block/mmcblk0 may have been damaged, but recovery works fine. I have access to CWM, adb and fastboot.
Is there a way to fix the partition table or some other way of making the partitions mountable?

I used adb shell for some diagnostics:

cat /proc/partitions
major minor #blocks name

179 0 62087168 mmcblk0
179 32 4096 mmcblk0boot1
179 16 4096 mmcblk0boot0
179 48 15558144 mmcblk1
179 49 15554048 mmcblk1p1

After a reboot (with a half installed Cyanogenmod) somehow, the output is:~ # cat /proc/partitions, but CWM still can't mount /data, /system, etc...
major minor #blocks name

179 0 62087168 mmcblk0
179 1 786432 mmcblk0p1
179 2 438272 mmcblk0p2
179 3 2048 mmcblk0p3
179 4 835584 mmcblk0p4
179 5 5120 mmcblk0p5
179 6 512 mmcblk0p6
179 7 5120 mmcblk0p7
179 8 59976192 mmcblk0p8
179 9 8192 mmcblk0p9
179 10 8192 mmcblk0p10
179 32 4096 mmcblk0boot1
179 16 4096 mmcblk0boot0
179 48 15558144 mmcblk1
179 49 15554048 mmcblk1p1

Output of dmesg| grep mmc
Code: 
dmesg|grep mmc
<5>[    0.000000] Kernel command line: tegra_wdt.heartbeat=30 tegraid=30.1.3.0.0 mem=1022M@2048M commchip_id=0 vmalloc=768M androidboot.serialno=015d29955e54260c androidboot.commchip_id=0 video=tegrafb no_console_suspend=1 console=ttyS0,115200n8 debug_uartport=lsport,0 usbcore.old_scheme_first=1 lp0_vec=8192@0xbddf9000 tegra_fbmem=9219840@0xabc01000 core_edp_mv=0 audio_codec=wm8903 board_info=245:0:fc:a6:29 tegraboot=sdmmc gpt gpt_sector=124174335 modem_id=0 android.kerneltype=recovery androidboot.productid=0x04 androidboot.carrier=wifi-only 
<6>[    0.805791] print_constraints: fixed_reg_en_3v3_emmc: 3300 mV normal standby
<6>[    0.805974] set_supply: fixed_reg_en_3v3_emmc: supplied by fixed_reg_en_3v3_sys
<6>[    3.640685] [mmc]:sdhci_tegra_probe:1152 mmc0: built_in 1
<4>[    3.642707] mmc0: Invalid maximum block size, assuming 512 bytes
<6>[    3.642994] mmc0: no vmmc regulator found
<7>[    3.644267] Registered led device: mmc0::
<6>[    3.646836] [mmc]:mmc_schedule_delayed_work:84 mmc0: delay 0
<6>[    3.646987] mmc0: SDHCI controller on sdhci-tegra.3 [sdhci-tegra.3] using ADMA
<4>[    3.648498] mmc1: Invalid maximum block size, assuming 512 bytes
<6>[    3.648779] mmc1: no vmmc regulator found
<7>[    3.650058] Registered led device: mmc1::
<6>[    3.652575] [mmc]:mmc_schedule_delayed_work:84 mmc1: delay 0
<6>[    3.652723] mmc1: SDHCI controller on sdhci-tegra.2 [sdhci-tegra.2] using ADMA
<6>[    3.653397] [mmc]:sdhci_tegra_probe:1099 mmc2: non-built_in 0
<4>[    3.656192] mmc2: Invalid maximum block size, assuming 512 bytes
<6>[    3.656475] mmc2: no vmmc regulator found
<7>[    3.657758] Registered led device: mmc2::
<6>[    3.660210] [mmc]:mmc_schedule_delayed_work:84 mmc2: delay 0
<6>[    3.660469] mmc2: SDHCI controller on sdhci-tegra.0 [sdhci-tegra.0] using ADMA
<6>[    3.761658] [mmc]:mmc_decode_cid:118 prv: 0x6f, manfid: 0x90
<6>[    3.773320] [mmc]:mmc_read_ext_csd:365 Boot Block Expose, boot size of mmc0 is 8388608
<6>[    3.775552] mmc0: new high speed DDR MMC card at address 0001
<6>[    3.776088] mmcblk mmc0:0001: Card claimed for testing.
<6>[    3.776781] mmcblk0: mmc0:0001 HYNIX  59.2 GiB 
<6>[    3.777369] mmcblk0boot0: mmc0:0001 HYNIX  partition 1 4.00 MiB
<6>[    3.778074] mmcblk0boot1: mmc0:0001 HYNIX  partition 2 4.00 MiB
<6>[    3.794728]  mmcblk0: p1 p2 p3 p4 p5 p6 p7 p8 p9 p10
<6>[    3.808067]  mmcblk0boot1: unknown partition table
<6>[    3.812871]  mmcblk0boot0: unknown partition table
<6>[    3.815515] [mmc]:mmc_rescan_try_freq:2010 mmc0: eMMC completed
<4>[    4.042757] mmc2: host does not support reading read-only switch. assuming write-enable.
<6>[    4.046107] mmc2: new high speed SDHC card at address e624
<6>[    4.046532] mmcblk mmc2:e624: Card claimed for testing.
<6>[    4.047366] mmcblk1: mmc2:e624 SU16G 14.8 GiB 
<6>[    4.058056]  mmcblk1: p1
<6>[    4.058913] [mmc]:mmc_rescan_try_freq:2006 mmc2: SD completed
<6>[    4.996531] [mmc]:mmc_schedule_delayed_work:84 mmc1: delay 0
<4>[    5.052746] mmc1 clock request: 50000KHz. currently 48000KHz
<6>[    5.054371] mmc1: new high speed SDIO card at address 0001
<6>[    5.062845] [mmc]:mmc_rescan_try_freq:2002 mmc1: sdio completed
<6>[    7.693501] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null)
<7>[    7.693580] SELinux: initialized (dev mmcblk0p2, type ext4), uses xattr

Can someone please shed some light on this? Thank you very much!
 
T

_that

Recognized Developer / Inactive RC
Oct 2, 2012
4,821
4,211
giza1928 said:
major minor #blocks name

179 0 62087168 mmcblk0
179 1 786432 mmcblk0p1
179 2 438272 mmcblk0p2
179 3 2048 mmcblk0p3
179 4 835584 mmcblk0p4
179 5 5120 mmcblk0p5
179 6 512 mmcblk0p6
179 7 5120 mmcblk0p7
179 8 59976192 mmcblk0p8
179 9 8192 mmcblk0p9
179 10 8192 mmcblk0p10
179 32 4096 mmcblk0boot1
179 16 4096 mmcblk0boot0
179 48 15558144 mmcblk1
179 49 15554048 mmcblk1p1
...
<6>[ 3.794728] mmcblk0: p1 p2 p3 p4 p5 p6 p7 p8 p9 p10
Click to expand...
Click to collapse

That looks quite correct. What happens when you try to mount /data manually?

mount -t ext4 /dev/block/mmcblk0p8 /data
Click to expand...
Click to collapse
 
  • Like
Reactions: giza1928
G

giza1928

Member
May 18, 2014
8
0
_that said:
That looks quite correct. What happens when you try to mount /data manually?
Click to expand...
Click to collapse

Thanks, good idea. But unfortunately, the error message isn't very detailed:

Code: 
mount -t ext4 /dev/block/mmcblk0p8 /data
mount: mounting /dev/block/mmcblk0p8 on /data failed: Invalid argument

I also tried to check the filesystem with e2fsck:

Code: 
~ # e2fsck /dev/block/mmcblk0p8 
e2fsck 1.41.14 (22-Dec-2010)
e2fsck: Superblock invalid, trying backup blocks...
e2fsck: Bad magic number in super-block while trying to open /dev/block/mmcblk0p8

The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>
 
Last edited:
T

_that

Recognized Developer / Inactive RC
Oct 2, 2012
4,821
4,211
giza1928 said:
Thanks, good idea. But unfortunately, the error message isn't very detailed:

Code: 
mount -t ext4 /dev/block/mmcblk0p8 /data
mount: mounting /dev/block/mmcblk0p8 on /data failed: Invalid argument
Click to expand...
Click to collapse

Is there any message in dmesg after trying this?

What do you get from "hexdump -C -n 2048 /dev/block/mmcblk0p8"?
 
  • Like
Reactions: giza1928
G

giza1928

Member
May 18, 2014
8
0
_that said:
Is there any message in dmesg after trying this?

What do you get from "hexdump -C -n 2048 /dev/block/mmcblk0p8"?
Click to expand...
Click to collapse

No, no messages in dmesg after the mount command, only updates like this:
Code: 
<4>[   81.890682] cpu ext_temperature=26

The output from the hexdump command:
Code: 
~ # hexdump -C -n 2048 /dev/block/mmcblk0p8 
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000800
 
T

_that

Recognized Developer / Inactive RC
Oct 2, 2012
4,821
4,211
giza1928 said:
The output from the hexdump command:
Code: 
~ # hexdump -C -n 2048 /dev/block/mmcblk0p8 
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000800
Click to expand...
Click to collapse

Funny. Normally the superblock should start at offset 0x400. Yours appears to have gotten wiped.

Try the same command on mmcblk0p1, mmcblk0p2, mmcblk0p3, mmcblk0p5 and post the results just to find out what's going on.
 
  • Like
Reactions: giza1928
G

giza1928

Member
May 18, 2014
8
0
_that said:
Funny. Normally the superblock should start at offset 0x400. Yours appears to have gotten wiped.

Try the same command on mmcblk0p1, mmcblk0p2, mmcblk0p3, mmcblk0p5 and post the results just to find out what's going on.
Click to expand...
Click to collapse

p1:
Code: 
hexdump -C -n 2048 /dev/block/mmcblk0p1
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000400  00 c0 00 00 00 00 03 00  00 00 00 00 95 ce 01 00  |................|
00000410  d2 b9 00 00 00 00 00 00  02 00 00 00 02 00 00 00  |................|
00000420  00 80 00 00 00 80 00 00  00 20 00 00 38 e3 78 53  |......... ..8.xS|
00000430  38 e3 78 53 05 00 ff ff  53 ef 01 00 02 00 00 00  |8.xS....S.......|
00000440  d2 aa 78 53 00 00 00 00  00 00 00 00 01 00 00 00  |..xS............|
00000450  00 00 00 00 0b 00 00 00  00 01 00 00 1c 00 00 00  |................|
00000460  42 00 00 00 13 00 00 00  57 f8 f4 bc ab f4 65 5f  |B.......W.....e_|
00000470  bf 67 94 6f c0 f9 f2 5b  00 00 00 00 00 00 00 00  |.g.o...[........|
00000480  00 00 00 00 00 00 00 00  2f 73 79 73 74 65 6d 00  |......../system.|
00000490  e8 0a 29 c0 00 9c a6 c7  b0 ca b7 c6 00 00 00 00  |..).............|
000004a0  48 b4 54 c7 e0 a3 58 c6  fc fd e0 c6 c8 fd e0 c6  |H.T...X.........|
000004b0  fc 7e 12 c0 80 f3 1a c0  e4 fd e0 c6 74 f3 1a c0  |.~..........t...|
000004c0  bc c7 7c c0 00 9c a6 c7  00 00 00 00 00 00 2f 00  |..|.........../.|
000004d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000004e0  08 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000004f0  00 00 00 00 00 00 00 00  00 00 00 00 02 01 20 00  |.............. .|
00000500  00 00 00 00 00 00 00 00  00 00 00 00 0a f3 01 00  |................|
00000510  03 00 00 00 00 00 00 00  00 00 00 00 00 0c 00 00  |................|
00000520  33 02 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |3...............|
00000530  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000550  00 00 00 00 00 00 00 00  00 00 00 00 1c 00 1c 00  |................|
00000560  02 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000570  00 00 00 00 00 00 00 00  ec 83 04 00 00 00 00 00  |................|
00000580  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000800
p2:
Code: 
~ # hexdump -C -n 2048 /dev/block/mmcblk0p2
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000400  00 6b 00 00 00 ac 01 00  00 00 00 00 86 86 01 00  |.k..............|
00000410  dc 6a 00 00 00 00 00 00  02 00 00 00 02 00 00 00  |.j..............|
00000420  00 80 00 00 00 80 00 00  c0 1a 00 00 f3 eb 78 53  |..............xS|
00000430  f3 eb 78 53 08 00 ff ff  53 ef 01 00 02 00 00 00  |..xS....S.......|
00000440  00 00 00 00 00 00 00 00  00 00 00 00 01 00 00 00  |................|
00000450  00 00 00 00 0b 00 00 00  00 01 00 00 1c 00 00 00  |................|
00000460  46 00 00 00 13 00 00 00  57 f8 f4 bc ab f4 65 5f  |F.......W.....e_|
00000470  bf 67 94 6f c0 f9 f2 5b  00 00 00 00 00 00 00 00  |.g.o...[........|
00000480  00 00 00 00 00 00 00 00  2f 63 61 63 68 65 00 e8  |......../cache..|
00000490  0a 29 c0 c0 dd d6 c6 88  d3 b8 c6 00 00 00 00 b8  |.)..............|
000004a0  eb b8 c6 20 cb 81 c7 fc  dd da c6 c8 dd da c6 fc  |... ............|
000004b0  7e 12 c0 80 f3 1a c0 e4  dd da c6 74 f3 1a c0 bc  |~..........t....|
000004c0  c7 7c c0 c0 dd d6 c6 d8  00 00 00 00 00 00 1f 00  |.|..............|
000004d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000004e0  08 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000004f0  00 00 00 00 00 00 00 00  00 00 00 00 02 01 20 00  |.............. .|
00000500  00 00 00 00 00 00 00 00  00 00 00 00 0a f3 01 00  |................|
00000510  03 00 00 00 00 00 00 00  00 00 00 00 b0 06 00 00  |................|
00000520  cf 01 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000530  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000550  00 00 00 00 00 00 00 00  00 00 00 00 1c 00 1c 00  |................|
00000560  02 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000570  00 00 00 00 00 00 00 00  ec 18 00 00 00 00 00 00  |................|
00000580  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000800
p3:
Code: 
~ # hexdump -C -n 2048 /dev/block/mmcblk0p3
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000800
p5:
Code: 
~ # hexdump -C -n 2048 /dev/block/mmcblk0p5
00000000  eb 58 90 42 53 44 20 20  34 2e 34 00 02 08 20 00  |.X.BSD  4.4... .|
00000010  02 00 00 00 28 f0 00 00  10 00 04 00 00 00 00 00  |....(...........|
00000020  00 00 00 00 0a 00 00 00  00 00 00 00 02 00 00 00  |................|
00000030  01 00 02 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000040  00 00 29 d2 07 38 a4 4e  4f 20 4e 41 4d 45 20 20  |..)..8.NO NAME  |
00000050  20 20 46 41 54 33 32 20  20 20 fa 31 c0 8e d0 bc  |  FAT32   .1....|
00000060  00 7c fb 8e d8 e8 00 00  5e 83 c6 19 bb 07 00 fc  |.|......^.......|
00000070  ac 84 c0 74 06 b4 0e cd  10 eb f5 30 e4 cd 16 cd  |...t.......0....|
00000080  19 0d 0a 4e 6f 6e 2d 73  79 73 74 65 6d 20 64 69  |...Non-system di|
00000090  73 6b 0d 0a 50 72 65 73  73 20 61 6e 79 20 6b 65  |sk..Press any ke|
000000a0  79 20 74 6f 20 72 65 62  6f 6f 74 0d 0a 00 00 00  |y to reboot.....|
000000b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..............U.|
00000200  52 52 61 41 00 00 00 00  00 00 00 00 00 00 00 00  |RRaA............|
00000210  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000003e0  00 00 00 00 72 72 41 61  ff ff ff ff 0d 00 00 00  |....rrAa........|
000003f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..............U.|
00000400  eb 58 90 42 53 44 20 20  34 2e 34 00 02 08 20 00  |.X.BSD  4.4... .|
00000410  02 00 00 00 28 f0 00 00  10 00 04 00 00 00 00 00  |....(...........|
00000420  00 00 00 00 0a 00 00 00  00 00 00 00 02 00 00 00  |................|
00000430  01 00 02 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000440  00 00 29 d2 07 38 a4 4e  4f 20 4e 41 4d 45 20 20  |..)..8.NO NAME  |
00000450  20 20 46 41 54 33 32 20  20 20 fa 31 c0 8e d0 bc  |  FAT32   .1....|
00000460  00 7c fb 8e d8 e8 00 00  5e 83 c6 19 bb 07 00 fc  |.|......^.......|
00000470  ac 84 c0 74 06 b4 0e cd  10 eb f5 30 e4 cd 16 cd  |...t.......0....|
00000480  19 0d 0a 4e 6f 6e 2d 73  79 73 74 65 6d 20 64 69  |...Non-system di|
00000490  73 6b 0d 0a 50 72 65 73  73 20 61 6e 79 20 6b 65  |sk..Press any ke|
000004a0  79 20 74 6f 20 72 65 62  6f 6f 74 0d 0a 00 00 00  |y to reboot.....|
000004b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000005f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..............U.|
00000600  52 52 61 41 00 00 00 00  00 00 00 00 00 00 00 00  |RRaA............|
00000610  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000007e0  00 00 00 00 72 72 41 61  ff ff ff ff 02 00 00 00  |....rrAa........|
000007f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..............U.|
00000800
Thanks already for your help, to be honest I have no clue what I'm looking at. Are those the first 2048 bits of each partition?
 
T

_that

Recognized Developer / Inactive RC
Oct 2, 2012
4,821
4,211
giza1928 said:
Thanks already for your help, to be honest I have no clue what I'm looking at. Are those the first 2048 bits of each partition?
Click to expand...
Click to collapse

Yes. All other partitions except /data look normal - p1 is /system, p2 is /cache, p3 is the bootloader command partition which is usually empty, p5 contains device configuration in a FAT32 filesystem.

Try formatting /data from the recovery, then reinstall your ROM (which will format and fill /system).
 
  • Like
Reactions: giza1928
G

giza1928

Member
May 18, 2014
8
0
_that said:
Yes. All other partitions except /data look normal - p1 is /system, p2 is /cache, p3 is the bootloader command partition which is usually empty, p5 contains device configuration in a FAT32 filesystem.

Try formatting /data from the recovery, then reinstall your ROM (which will format and fill /system).
Click to expand...
Click to collapse

Ok, do you mean the format command I can select in recovery? Because it says:
Code: 
Formatting /data...
Error mounting /data!
Skipping format...
Done.
But can I maybe use mke2fs or something similar to format /dev/mmcblk0p8? If so, could you tell me what options I should use?
Thanks
 
T

_that

Recognized Developer / Inactive RC
Oct 2, 2012
4,821
4,211
giza1928 said:
Ok, do you mean the format command I can select in recovery? Because it says:
Code: 
Formatting /data...
Error mounting /data!
Skipping format...
Done.
Click to expand...
Click to collapse

I have no experience with CWM; apparently it sucks. ;)

giza1928 said:
But can I maybe use mke2fs or something similar to format /dev/mmcblk0p8? If so, could you tell me what options I should use?
Click to expand...
Click to collapse

Code: 
make_ext4fs /dev/block/mmcblk0p8

should do it. Assuming that CWM ships with a make_ext4fs binary.
 
  • Like
Reactions: giza1928
V

Viking8

Senior Member
Nov 25, 2013
121
59
Phoenix
I figured I would post my experience with a sudden bootloop. My tf700t was unlocked and rooted a very long time ago and I've used a few ROM's since doing that. First was CROMI-x then Cyanogenmod 11 nightlies then CROMBi-kk and then I switched to ZOMBI-x.
I installed Zombi-x using F2FS file system and never had any issues except for the usual mind numbing lag from the horrible IO issues.

So just last night (12/21/2014) my tablet froze with a light grey screen and about 10 seconds later it rebooted, but it kept rebooting over and over. I tried cold booting, but that didn't help, so I booted into CWM (ver. 6.0.4.7) and tried to do a wipe data/system reset, but the tablet would just reboot part way through. I tried formatting the /data partition directly but it caused the tablet to reboot as well. So a few other posts around the interwebs led me to the conclusion that I needed to get rid of clockworkmod and switch to TWRP.

Thankfully I was able to connect to the tablet using fastboot, but only in Linux. (my Win7 PC saw that something was there, but it wouldn't let me install the driver)(http://lifehacker.com/the-easiest-way-to-install-androids-adb-and-fastboot-to-1586992378) So I installed TWRP 2.8.3.0 and used it to do a complete wipe. It started the format but had several errors about not being able to mount /data and then it said it was formatting Data using ext4fs. I've read that it should only take 5 minutes or so, so you can imagine my worry when 5 minutes past and then 10 and so on until it finished up after a little over 30 minutes, so if it's just sitting there, there's a good chance it is actually doing something, so leave it be for awhile and don't forget to check your battery, you don't want your tab to shut off suddenly!

I reinstalled CROMBi-kk and let it boot. Much to my surprise it booted and the resulting performance was nothing short of shocking!
So far this thing is running like it NEVER has before! The lag so far is so much less than ever and things open and close very quickly!
So without any surprise here, I won't be using F2FS anymore for fear I'll have corruption on the internal storage again! Thankfully TWRP came through for me. So if your tf700 is bootlooping and you still have fastboot, try installing the latest TWRP, it may just make the difference between a functioning tablet and a brick!
 
T

_that

Recognized Developer / Inactive RC
Oct 2, 2012
4,821
4,211
Viking8 said:
So I installed TWRP 2.8.3.0 and used it to do a complete wipe. It started the format but had several errors about not being able to mount /data and then it said it was formatting Data using ext4fs. I've read that it should only take 5 minutes or so, so you can imagine my worry when 5 minutes past and then 10 and so on until it finished up after a little over 30 minutes, so if it's just sitting there, there's a good chance it is actually doing something, so leave it be for awhile and don't forget to check your battery, you don't want your tab to shut off suddenly!

I reinstalled CROMBi-kk and let it boot. Much to my surprise it booted and the resulting performance was nothing short of shocking!
So far this thing is running like it NEVER has before! The lag so far is so much less than ever and things open and close very quickly!
Click to expand...
Click to collapse

The long time it takes for formatting and the performance gains are actually related. Creating the filesystem takes probably less than 5 minutes, but then the recovery does a "trim" on the free blocks - telling the eMMC that it may discard the data in these blocks and erase them. Erasing flash memory is slow. But following write requests by the booted ROM will be much faster because they can be written directly without prior erasing and shuffling data around.
 
  • Like
Reactions: Ozark_8125, lj50036, berndblb and 1 other person
berndblb

berndblb

Inactive Recognized Contributor
Nov 22, 2012
4,875
2,113
Los Angeles, CA
_that said:
The long time it takes for formatting and the performance gains are actually related. Creating the filesystem takes probably less than 5 minutes, but then the recovery does a "trim" on the free blocks - telling the eMMC that it may discard the data in these blocks and erase them. Erasing flash memory is slow. But following write requests by the booted ROM will be much faster because they can be written directly without prior erasing and shuffling data around.
Click to expand...
Click to collapse
So the performance boost after formatting /data is temporary until the emmc again has to shuffle data around when it gets write requests?
I thought f2fs was supposed to take care of that?
 
T

_that

Recognized Developer / Inactive RC
Oct 2, 2012
4,821
4,211
berndblb said:
So the performance boost after formatting /data is temporary until the emmc again has to shuffle data around when it gets write requests?
I thought f2fs was supposed to take care of that?
Click to expand...
Click to collapse

Using f2fs should increase the time until the eMMC has to shuffle data around because it does less random writes. But when all blocks have been written once, something must be erased to rewrite more. The permanent solution is to run fstrim regularly (I've seen some comments in the Android source code that runs it automatically from time to time) or to mount with the discard option, and to leave a reasonable amount of space free (10 to 15%).
 
  • Like
Reactions: sziggins and berndblb
berndblb

berndblb

Inactive Recognized Contributor
Nov 22, 2012
4,875
2,113
Los Angeles, CA
_that said:
Using f2fs should increase the time until the eMMC has to shuffle data around because it does less random writes. But when all blocks have been written once, something must be erased to rewrite more. The permanent solution is to run fstrim regularly (I've seen some comments in the Android source code that runs it automatically from time to time) or to mount with the discard option, and to leave a reasonable amount of space free (10 to 15%).
Click to expand...
Click to collapse
Enlightening as always! Happy Holidays to you and your family!
[emoji319] [emoji319] [emoji318] [emoji319] [emoji319]
 
  • Like
Reactions: _that and sziggins
You must log in or register to reply here.

Similar threads

T
The ASUS Transformer Pad Infinity Thread
Replies
4K
Views
880K
S
Shin-GTX
F
Bootloop + E:unable to mount /data
Replies
103
Views
116K
T
_that
L
  • Locked
[Q&A]★★★[TF700 KitKat 4.4.4][CROMBi-kk-R1][Sep 21]★★★
Replies
5K
Views
392K
L
lj50036
dasunsrule32
[ROOT][CWM] root.zip - ChainsDD Superuser.apk and su built from source
Replies
31
Views
105K
HemanthJabalpuri
HemanthJabalpuri
sbdags
  • Locked
[ROM]&#9733;&#9733;[TF700 KitKat 4.4.4r2][CROMBi-kk R1][Sep 21]&#9733;&#9733;
Replies
2K
Views
556K
sbdags
sbdags

Top Liked Posts

24 Hours All time
  • There are no posts matching your filters.
  • 4
    T
    _that
    Viking8 said:
    So I installed TWRP 2.8.3.0 and used it to do a complete wipe. It started the format but had several errors about not being able to mount /data and then it said it was formatting Data using ext4fs. I've read that it should only take 5 minutes or so, so you can imagine my worry when 5 minutes past and then 10 and so on until it finished up after a little over 30 minutes, so if it's just sitting there, there's a good chance it is actually doing something, so leave it be for awhile and don't forget to check your battery, you don't want your tab to shut off suddenly!

    I reinstalled CROMBi-kk and let it boot. Much to my surprise it booted and the resulting performance was nothing short of shocking!
    So far this thing is running like it NEVER has before! The lag so far is so much less than ever and things open and close very quickly!
    Click to expand...
    Click to collapse

    The long time it takes for formatting and the performance gains are actually related. Creating the filesystem takes probably less than 5 minutes, but then the recovery does a "trim" on the free blocks - telling the eMMC that it may discard the data in these blocks and erase them. Erasing flash memory is slow. But following write requests by the booted ROM will be much faster because they can be written directly without prior erasing and shuffling data around.
    View
    2
    berndblb
    berndblb
    _that said:
    Using f2fs should increase the time until the eMMC has to shuffle data around because it does less random writes. But when all blocks have been written once, something must be erased to rewrite more. The permanent solution is to run fstrim regularly (I've seen some comments in the Android source code that runs it automatically from time to time) or to mount with the discard option, and to leave a reasonable amount of space free (10 to 15%).
    Click to expand...
    Click to collapse
    Enlightening as always! Happy Holidays to you and your family!
    [emoji319] [emoji319] [emoji318] [emoji319] [emoji319]
    View
    2
    T
    _that
    berndblb said:
    So the performance boost after formatting /data is temporary until the emmc again has to shuffle data around when it gets write requests?
    I thought f2fs was supposed to take care of that?
    Click to expand...
    Click to collapse

    Using f2fs should increase the time until the eMMC has to shuffle data around because it does less random writes. But when all blocks have been written once, something must be erased to rewrite more. The permanent solution is to run fstrim regularly (I've seen some comments in the Android source code that runs it automatically from time to time) or to mount with the discard option, and to leave a reasonable amount of space free (10 to 15%).
    View
    1
    T
    _that
    giza1928 said:
    major minor #blocks name

    179 0 62087168 mmcblk0
    179 1 786432 mmcblk0p1
    179 2 438272 mmcblk0p2
    179 3 2048 mmcblk0p3
    179 4 835584 mmcblk0p4
    179 5 5120 mmcblk0p5
    179 6 512 mmcblk0p6
    179 7 5120 mmcblk0p7
    179 8 59976192 mmcblk0p8
    179 9 8192 mmcblk0p9
    179 10 8192 mmcblk0p10
    179 32 4096 mmcblk0boot1
    179 16 4096 mmcblk0boot0
    179 48 15558144 mmcblk1
    179 49 15554048 mmcblk1p1
    ...
    <6>[ 3.794728] mmcblk0: p1 p2 p3 p4 p5 p6 p7 p8 p9 p10
    Click to expand...
    Click to collapse

    That looks quite correct. What happens when you try to mount /data manually?

    mount -t ext4 /dev/block/mmcblk0p8 /data
    Click to expand...
    Click to collapse
    View
    1
    T
    _that
    giza1928 said:
    Thanks, good idea. But unfortunately, the error message isn't very detailed:

    Code: 
    mount -t ext4 /dev/block/mmcblk0p8 /data
mount: mounting /dev/block/mmcblk0p8 on /data failed: Invalid argument
    Click to expand...
    Click to collapse

    Is there any message in dmesg after trying this?

    What do you get from "hexdump -C -n 2048 /dev/block/mmcblk0p8"?
    View

New posts