How to convert to EXT4 non-destructively from EXT3 for SD-EXT and Dalvik when you have activated A2SD chachesd and A2SD datasd?
EXT3 > EXT4
Easy. Don't convert. Ext4 spoils your card.
Sent from my GT-S5830 using XDA App
http://www.ibm.com/developerworks/linux/library/l-ext4/
is a good resource for this.
http://ext3vsext4.com/2011/06/ext4-compared-to-ext3/
Something else to read
http://gparted.sourceforge.net/
or try this.
Hope it helps.
Baracs said:
http://www.ibm.com/developerworks/linux/library/l-ext4/
is a good resource for this.
http://ext3vsext4.com/2011/06/ext4-compared-to-ext3/
Something else to read
http://gparted.sourceforge.net/
or try this.
Hope it helps.
Click to expand...
Click to collapse
I booted into Ubuntu Linux LiveCD then
Converting ext3 to ext4
If you are upgrading /dev/sda2 that is mounted as /home, from ext3 to ext4, do the following.
umount /dev/sda2
tune2fs -O extents,uninit_bg,dir_index /dev/sda2
e2fsck -pf /dev/sda2
mount /dev/sda2 /home
Again, try all of the above commands only on a test system, where you can afford to lose all your data.
Click to expand...
Click to collapse
from http://www.thegeekstuff.com/2011/05/ext2-ext3-ext4/
Although in Minitool Partition Wizard Home Edition, no matter how many times I refresh it, the EXT4 partition that shows as /dev/sdb2 in GParted always shows as EXT3. Maybe a program limitation?
Why?
consegregate said:
Easy. Don't convert. Ext4 spoils your card
Click to expand...
Click to collapse
Why does it spoil the card? Did it spoil your card with data=writeback (no journalling) mode or without?
Well, I've just had a complete corruption of my ext4 /sd-ext/ *with* journalling, and rebooting into recovery and using e2fsck on the unmounted partition couldn't fix the filesystem:
Code:
e2fsck: Invalid argument passed to ext2 library while rewriting block and inode bitmaps for /dev/block/mmcblk0p2
Not sure why ext2 library error occurs with e2fsck, but no way to fix, had to do a full recover of sd-ext using CWM...
I've not used ext2, but do note that cyanogenmod 7.2 always mounts /sd-ext/ as ext3, I suppose for a reason...
Hey folks.
So, I have installed a custom rom to an android box, it runs on EXT4 itself for the system but if I try to connect an external hard drive formatted as EXT4 it only says it's unsupported and will give me the option to format it, which I won't do. I don't want FAT32 or ExFAT or NTFS. I need EXT4 for reasons.
I was using this hard drive with my RaspberryPi before and it worked fine. Also this box is rooted and I can mount it manually with "mount -t ext4 /dev/block/sda /mnt/hd" or whatever and I can see the files, have read/write BUT other apps can't see it due to Android security (even messing with chown/chmod).
I'm not sure how to add EXT4 support to mountable storage at all to a ROM. The dev seems to be busy with other projects and won't help, so I have to figure it out on my own.
I have searched left and right but couldn't find any answer on how to do it myself, nothing very conclusive.
Should I just add the hdd to fstab.amlogic? Does it have anything to do with vold? I wanted the system to be able to recognize it and mount it, not mount it myself like this.
Futher info:
This is the BLKID for the hdd:
Code:
/dev/block/sda: UUID="4de...d5" TYPE="ext4"
/dev/block/vold/disk:8,0: UUID="4de...d5" TYPE="ext4"
This is the fstab.amlogic:
Code:
# Android fstab file.
#<src> <mnt_point> <type> <mnt_flags and options> <fs_mgr_flags>
# The filesystem that contains the filesystem checker binary (typically /system) cannot
# specify MF_CHECK, and must come before any filesystems that do specify MF_CHECK
/dev/block/misc /misc emmc defaults defaults
/dev/block/system /system ext4 ro wait
/dev/block/data /data ext4 noatime,nosuid,nodev,nodelalloc,nomblk_io_submit,errors=panic wait,check,encryptable=footer
/dev/block/cache /cache ext4 noatime,nosuid,nodev,nodelalloc,nomblk_io_submit,errors=panic wait,check
/devices/*.sd/mmc_host/sd* auto auto defaults voldmanaged=sdcard1:auto,noemulatedsd
/devices/*dwc3/xhci-hcd.0.auto/usb?/*/host*/target*/block/sd* auto auto defaults voldmanaged=udisk:auto
/devices/*dwc3/xhci-hcd.0.auto/usb?/*/host*/target*/block/sr* auto auto defaults voldmanaged=sr0:auto
/dev/block/loop auto loop defaults voldmanaged=loop:auto
# Add for zram. zramsize can be in numeric (byte) , in percent
/dev/block/zram0 /swap_zram0 swap defaults wait,zramsize=524288000
/dev/block/tee /tee ext4 noatime,nosuid,nodev,nodelalloc,nomblk_io_submit,errors=panic wait,check
Thank you.
ive created a boot.img maybe someone can try and report back - in theory it should speed up /data /system and /cache partitions by the fstab flags set.
also uploaded the default boot.img from oxygen 4-7-5 (please make sure you're on 4-7-5) maybe someone can help fix this if it doesnt work.
please note this may wipe all storage / etc etc take all necessary precautions (external backup etc) until we get it working 100% as i havent tested
this work is open to anyone who'd like to use it.
Cliffs
- ive modified boot.img to try and disable verity and force encrypt - also enabling / disabling certain IO functions to improve throughput
- i need someone to go into twrp > flash the modifiedboot.img then format /data and check if it boots (i.e boots into OS if it does please report back)
-please make all necessary backups incase it doesnt work
-attached stock boot.img incase it doesnt work (please make external backup too)
here are my attempts:
Modified boot.img:
https://drive.google.com/open?id=154jrUAQ1oq7Fpjw7PgBKCJ_E6yBCxvaQ
stock boot.img
https://drive.google.com/open?id=17JU_OiEGdGm_9K1TcYlFtEkiiTJmODve
please report back if it works or not (i.e does it boot into OS or hang?)
background
my previous android phones ive created a perfect boot image whereby i edit the fstab in the boot.img
to disable force encryption and apply other android attributed in the fstab.
however i do not yet have my 1+5T as of yet so i can not try the edits as the boot.img is alittle different from my previous android phones.
The stock boot.img for the oneplus 5T (extracted from 4-7-5)
has two fstab files
the first fstab.qcom, and the second fstab_nodata.qcom
both these fstab are alittle different.
fstab.qcom looks like this:
Code:
#<src> <mnt_point> <type> <mnt_flags and options> <fs_mgr_flags>
/dev/block/bootdevice/by-name/system /system ext4 ro,barrier=1,discard,errors=panic wait,verify
/dev/block/bootdevice/by-name/userdata /data f2fs noatime,nosuid,nodev,discard,nodiratime,inline_xattr wait,check,forceencrypt=footer,resize
/dev/block/bootdevice/by-name/userdata /data ext4 nosuid,nodev,barrier=1,noauto_da_alloc,discard,errors=panic wait,check,fileencryption=ice,resize
#/devices/soc/c0a4900.sdhci/mmc_host* /storage/sdcard1 vfat nosuid,nodev wait,voldmanaged=sdcard1:auto,encryptable=footer
/dev/block/zram0 none swap defaults zramsize=536870912
/dev/block/bootdevice/by-name/misc /misc emmc defaults defaults
/dev/block/bootdevice/by-name/modem /firmware vfat ro,shortname=lower,uid=1000,gid=1000,dmask=227,fmask=337,context=u:object_r:firmware_file:s0 wait
/dev/block/bootdevice/by-name/bluetooth /bt_firmware vfat ro,shortname=lower,uid=1002,gid=3002,dmask=227,fmask=337,context=u:object_r:bt_firmware_file:s0 wait
/dev/block/bootdevice/by-name/cache /cache ext4 rw,nosuid,nodev,barrier=1 wait,check
/devices/soc/a800000.ssusb/a800000.dwc3/xhci-hcd.0.auto/usb* auto auto defaults voldmanaged=usbotg:auto
and fstab_nodata.qcom looks like this:
Code:
#<src> <mnt_point> <type> <mnt_flags and options> <fs_mgr_flags>
/dev/block/bootdevice/by-name/system /system ext4 ro,barrier=1,discard wait,verify
#/dev/block/bootdevice/by-name/userdata /data ext4 nosuid,nodev,barrier=1,noauto_da_alloc,discard,errors=panic wait,check,forceencrypt=footer,resize
tmpfs /data tmpfs defaults defaults
#/devices/soc/c0a4900.sdhci/mmc_host* /storage/sdcard1 vfat nosuid,nodev wait,voldmanaged=sdcard1:auto,encryptable=footer
/dev/block/zram0 none swap defaults zramsize=536870912
/dev/block/bootdevice/by-name/misc /misc emmc defaults defaults
/dev/block/bootdevice/by-name/modem /firmware vfat ro,shortname=lower,uid=1000,gid=1000,dmask=227,fmask=337,context=u:object_r:firmware_file:s0 wait
/dev/block/bootdevice/by-name/bluetooth /bt_firmware vfat ro,shortname=lower,uid=1002,gid=3002,dmask=227,fmask=337,context=u:object_r:bt_firmware_file:s0 wait
/dev/block/bootdevice/by-name/cache /cache ext4 rw,nosuid,nodev,barrier=1 wait
/devices/soc/a800000.ssusb/a800000.dwc3/xhci-hcd.0.auto/usb* auto auto defaults voldmanaged=usbotg:auto
as you can see these two files are alittle different - previous android devices have only had one fstab file.
so my first question why are there two fstab files? - anywho ive added my modifications to both where applicable.
secondly the modified fstab id like to introduce is the following:
Code:
/dev/block/bootdevice/by-name/system /system ext4 ro,noatime,noauto_da_alloc,nodev,nodiratime,barrier=0,data=writeback,nobh wait
/dev/block/bootdevice/by-name/userdata /data f2fs nosuid,nodev,noatime,nodiratime,discard,inline_data,inline_xattr wait,check,encryptable,resize
/dev/block/bootdevice/by-name/userdata /data ext4 noatime,nosuid,nodev,nodiratime,barrier=0,data=writeback,noauto_da_alloc,discard,nobh wait,check,encryptable,resize
/dev/block/bootdevice/by-name/cache /cache ext4 rw,nosuid,nodev,noatime,noauto_da_alloc,nodiratime,barrier=0,data=writeback,nobh wait,check
virtyx said:
Hi guys
my previous android phones ive created a perfect boot image whereby i edit the fstab in the boot.img
to disable force encryption and apply other android attributed in the fstab.
however i do not yet have my 1+5T as of yet so i can not try the edits as the boot.img is alittle different from my previous android phones.
The stock boot.img for the oneplus 5T (extracted from 4-7-5)
has two fstab files
the first fstab.qcom, and the second fstab_nodata.qcom
both these fstab are alittle different.
fstab.qcom looks like this:
and fstab_nodata.qcom looks like this:
as you can see these two files are alittle different - previous android devices have only had one fstab file.
so my first question why are there two fstab files? - anywho ive added my modifications to both where applicable.
secondly the modified fstab id like to introduce is the following:
ive created a boot.img maybe someone can try and report back - in theory it should speed up /data /system and /cache partitions by the fstab flags set.
also uploaded the default boot.img from oxygen 4-7-5 (please make sure you're on 4-7-5) maybe someone can help fix this if it doesnt work.
please note this may wipe all storage / etc etc take all necessary precautions (external backup etc) until we get it working 100% as i havent tested
this work is open to anyone who'd like to use it.
here are my attempts:
Modified boot.img:
https://drive.google.com/open?id=1BYH4J3Du9VBRyxM1hyTQhs_hKNLgOU0W
stock boot.img
https://drive.google.com/open?id=1IpByGusbuWXKOXGKamHHEwax3aSnsvfm
please report back if it works or not (i.e does it boot into OS or hang?)
Click to expand...
Click to collapse
You also need to make the kernel compatible, without verity. Otherwise won't boot
jgcaap said:
You also need to make the kernel compatible, without verity. Otherwise won't boot
Click to expand...
Click to collapse
please read OP again as ive done this
by default force encryption on /data is enabled, and dm-verify is enabled...boot.img needs to be modified to disable. also /data will have to be formatted to flash ROMS.
with dm-verify enabled, any changes to /system will cause no boot
to modify boot.img:
Code:
open /ramdisk/fstab.qcom
change:
/dev/block/bootdevice/by-name/system /system ext4 ro,barrier=1 wait,verify
/dev/block/bootdevice/by-name/userdata /data ext4 nosuid,nodev,barrier=1,noauto_da_alloc,discard,errors=continue wait,check,formattable,forceencrypt=/dev/block/bootdevice/by-name/extra
to:
/dev/block/bootdevice/by-name/system /system ext4 ro,barrier=1 wait
/dev/block/bootdevice/by-name/userdata /data ext4 nosuid,nodev,barrier=1,noauto_da_alloc,discard,errors=continue wait,check,formattable,encryptable=/dev/block/bootdevice/by-name/extra
virtyx said:
If we flash the boot.Img then another kernel may it work? @jgcaap how would we get it to work?
Never needed to do that on a previous android
Click to expand...
Click to collapse
You need to compile kernel that will allow to boot without the verity and change the ram disk.
benny3 said:
by default force encryption on /data is enabled, and dm-verify is enabled...boot.img needs to be modified to disable. also /data will have to be formatted to flash ROMS.
with dm-verify enabled, any changes to /system will cause no boot
to modify boot.img:
Code:
open /ramdisk/fstab.qcom
change:
/dev/block/bootdevice/by-name/system /system ext4 ro,barrier=1 wait,verify
/dev/block/bootdevice/by-name/userdata /data ext4 nosuid,nodev,barrier=1,noauto_da_alloc,discard,errors=continue wait,check,formattable,forceencrypt=/dev/block/bootdevice/by-name/extra
to:
/dev/block/bootdevice/by-name/system /system ext4 ro,barrier=1 wait
/dev/block/bootdevice/by-name/userdata /data ext4 nosuid,nodev,barrier=1,noauto_da_alloc,discard,errors=continue wait,check,formattable,encryptable=/dev/block/bootdevice/by-name/extra
Click to expand...
Click to collapse
which is why ive asked users to format /data before flashing the boot.img which should disable verity and forceencrypt
jgcaap said:
You need to compile kernel that will allow to boot without the verity and change the ram disk.
Click to expand...
Click to collapse
this is what im doing...
so if someone is brave enough to test this (as i dont have a 1+5T yet)
format /data then using mtp trasnfer the modifiedboot.img to the phone, then flash modified boot.img
and see if you can boot into OS if you can please report back.
updated the modifiedboot.img to omit discard flag - should slightly improve performance but requires a cron job to manually trim partitions, automatic trim can cause hangs upon large file deletion, plus i dont find the need to run trim on the block layer every time a file is deleted, i would rather run it daily with a cron job.
Isn't this what the disable force encryption and disable no verity zip is for? To flash over stock boot image and allow boot on a decrypted device by disabling Force encryption and no verity.?
yung40oz84 said:
Isn't this what the disable force encryption and disable no verity zip is for? To flash over stock boot image and allow boot on a decrypted device by disabling Force encryption and no verity.?
Click to expand...
Click to collapse
yes, those zips only remove verity and force encryption
this boot img includes other tweaks not found elsewhere (ie, data writeback, barrier=0, noatime, nodiratime, noautoalloc, disabling auto-trim, etc) which all theoretically should improve throughput while reducing overhead
virtyx said:
yes, those zips only remove verity and force encryption
this boot img includes other tweaks not found elsewhere (ie, data writeback, barrier=0, noatime, nodiratime, noautoalloc, disabling auto-trim, etc) which all theoretically should improve throughput while reducing overhead
Click to expand...
Click to collapse
Doesn't the auto-trim flag keeps the NAND flash healthy and prevents data corruption? ?
ground-zero said:
Doesn't the auto-trim flag keeps the NAND flash healthy and prevents data corruption? ?
Click to expand...
Click to collapse
No, doesnt prevent corruption.
we dont need the trim command to run every time a file is deleted that just causes unnecessary overhead, its better if we run the trim command daily via a cron job.
(imagine deleting files and running the trim command everytime we do so, its not needed, the OS does adequate garbage collection and the Trim command gets issued automatically from android 5 so its not needed to add it in the fstab)
for your reading
https://wiki.archlinux.org/index.php/Solid_State_Drives#Periodic_TRIM