While messing around with ext2 and data2ext i noticed that android doesn't umount the sd-ext partition (Vold process unmounts the fat partition just fine as it can be seen with logcat). Also cyanogen states the same in this posting (Im wasn't sure on this but i don't doubt him EDIT: i doubt him now ... ).
I wonder now why the recommended solution for file corruption issues is using ext3/4 (wich slows things down due to the journal and reduces the lifetime of flashdrives due to limited r/w cycles) instead of just make a shutdown script wich unmounts the ext partition? (About lifetime: I think 10.000-100.000 r/w cycles is a rather high value and lifetime is only a theoretical and not a practical issue - but im not sure on this)
Since i'm not really expirenced in scripting on either linux or android i wanted to ask if a script in "init.d/rc0.d" (+"init.d/rc6.d" for reboot) would be possible? I could write one but i don't know if this would be executed and i actually don't know how i could check if it works (i think logcat would be shutdown before this is done).
Edit: At least if rc0.d scripts are run BEFORE logcat stops it doesn't work. Logcat log is empty if i "grep test" an "echo "test"" script.
Need help. Someone ...
melethron said:
While messing around with ext2 and data2ext i noticed that android doesn't umount the sd-ext partition (Vold process unmounts the fat partition just fine as it can be seen with logcat). Also cyanogen states the same in this posting (Im wasn't sure on this but i don't doubt him ).
I wonder now why the recommended solution for file corruption issues is using ext3/4 (wich slows things down due to the journal and reduces the lifetime of flashdrives due to limited r/w cycles) instead of just make a shutdown script wich unmounts the ext partition? (About lifetime: I think 10.000-100.000 r/w cycles is a rather high value and lifetime is only a theoretical and not a practical issue - but im not sure on this)
Since i'm not really expirenced in scripting on either linux or android i wanted to ask if a script in "init.d/rc0.d" (+"init.d/rc6.d" for reboot) would be possible? I could write one but i don't know if this would be executed and i actually don't know how i could check if it works (i think logcat would be shutdown before this is done).
Click to expand...
Click to collapse
Does /system/bin/shutdown get called to turn off the phone?
Logcat looks like its the last thing to stop
coutts99 said:
Does /system/bin/shutdown get called to turn off the phone?
Logcat looks like its the last thing to stop
Click to expand...
Click to collapse
Code:
adb logcat | grep /system/bin/shutdown > ~/shutdowntest.log
Empty file
Although the file is present in ROM's so maybe it IS called after logcat stops. But i don't know if it's added to Custom ROMs and if it's also present in RUU's.
If it's not called do you see any possibility to use "Vold" process? Cause it does the unmounting:
Code:
I/Vold ( 145): /mnt/secure/staging/.android_secure sucessfully unmounted
I/Vold ( 145): /mnt/secure/asec sucessfully unmounted
I/Vold ( 145): /mnt/secure/staging sucessfully unmounted
I/Vold ( 145): /mnt/sdcard unmounted sucessfully
D/Vold ( 145): Volume sdcard state changing 5 (Unmounting) -> 1 (Idle-Unmounted)
melethron said:
Code:
adb logcat | grep /system/bin/shutdown > ~/shutdowntest.log
Empty file
Although the file is present in ROM's so maybe it IS called after logcat stops. But i don't know if it's added to Custom ROMs and if it's also present in RUU's.
If it's not called do you see any possibility to use "Vold" process? Cause it does the unmounting:
Code:
I/Vold ( 145): /mnt/secure/staging/.android_secure sucessfully unmounted
I/Vold ( 145): /mnt/secure/asec sucessfully unmounted
I/Vold ( 145): /mnt/secure/staging sucessfully unmounted
I/Vold ( 145): /mnt/sdcard unmounted sucessfully
D/Vold ( 145): Volume sdcard state changing 5 (Unmounting) -> 1 (Idle-Unmounted)
Click to expand...
Click to collapse
hmm, interesting. Maybe have to poke through the source and see what is called to shutdown the phone.
Sent from my HTC Desire using XDA App
coutts99 said:
hmm, interesting. Maybe have to poke through the source and see what is called to shutdown the phone.
Sent from my HTC Desire using XDA App
Click to expand...
Click to collapse
I think this would be a major improvement. Since journaling is actually bad for sd's. Im not sure on this, but the journal is in some specific area on the filesystem. If this is the case I'm not sure if algorithms used to distribute r/w on flash drives will help if the journal gets overwritten (as i understand it so far the r/w is distributet over FREE space but not if something gets overwriten). If this is the case the part of the SD with the journal will be stressed heavy.
I've been playing around with data2sd with ext2 for a few weeks now.
I might be wrong but I think that the system is unmounting cleanly /data (and not /dev/block/mtdblock5) because I always have a clean e2fsck log after rebooting the phone.
So basically if you mount something under the /data mountpoint, it won't be cleanly unmounted and you'll end-up with corrupted FS. That what happens for A2SD because /data is still /dev/block/mtdblock5. But if you mount straight over /data, like I do with DATA2SD, the system unmounts /data on shutdown, witch is now your ext partition (whether your ext partition or a file on ext partition mounted via a loop device) and your FS is not corrupted. In that case you don't need journaling and can stick with ext2.
sibere said:
I've been playing around with data2sd with ext2 for a few weeks now.
I might be wrong but I think that the system in unmounting cleanly /data (and not /dev/block/mtdblock5) because I always have a clean e2fsck log after rebooting the phone.
So basically if you mount something under the /data mountpoint, it won't be cleanly unmounted and you'll end-up with corrupted FS. That what happens for A2SD because /data is still /dev/block/mtdblock5. But if you mount straight over /data, like I do with DATA2SD, the system unmounts /data on shutdown, witch is now your ext partition (whether your ext partition or a file on ext partition mounted via a loop device) and your FS is not corrupted. In that case you don't need journaling and can stick with ext2.
Click to expand...
Click to collapse
Im pretty sure for 3 reasons that it doesnt unmount data:
1. Android unmounts "/sdcard" as it can be seen in logcat while other stuff isn't unmounted. It may be still that the other unmount stuff is not not by the "Vold" process. Sdcard needs to be able to get unmounted when the phone is plugged to usb.
2. I also did quite a lot testing with sd-ext directly mounted to /data and i did get quite a lot corruption. But it is situation depended. If my phone was "idle" i didn't get corruption (1 time in 20 reboots) with no corruption. Then to make absolutly sure that it works i shut it down right after it boots up. There is many stuff running then wich means there is a much higher chance that something is still written while it shutdowns. Doing this i had corruption every 3rd reboot.
3. And this is the most important reason why you didn't get corruption but i did : You use sync as a mount option so you there is no need to unmount it ^^ !!!!
Sync is not an option for me for some reason:
-No cache will slowdown write on small files heavily
-Without cache every other process has to wait if some writing is done (lags).
-Much more wear for the sd since small files aren't cached
Using ext2 with sync isn't an option for me. Either i get ext2 with a proper unmount to work or i'll use Ext4 with an "ordered" journal then (or maybe i give a s*** about data2ext then).
melethron said:
Im pretty sure for 3 reasons that it doesnt unmount data:
1. Android unmounts "/sdcard" as it can be seen in logcat while other stuff isn't unmounted. It may be still that the other unmount stuff is not not by the "Vold" process. Sdcard needs to be able to get unmounted when the phone is plugged to usb.
2. I also did quite a lot testing with sd-ext directly mounted to /data and i did get quite a lot corruption. But it is situation depended. If my phone was "idle" i didn't get corruption (1 time in 20 reboots) with no corruption. Then to make absolutly sure that it works i shut it down right after it boots up. There is many stuff running then wich means there is a much higher chance that something is still written while it shutdowns. Doing this i had corruption every 3rd reboot.
3. And this is the most important reason why you didn't get corruption but i did : You use sync as a mount option so you there is no need to unmount it ^^ !!!!
Sync is not an option for me for some reason:
-No cache will slowdown write on small files heavily
-Without cache every other process has to wait if some writing is done (lags).
-Much more wear for the sd since small files aren't cached
Using ext2 with sync isn't an option for me. Either i get ext2 with a proper unmount to work or i'll use Ext4 with an "ordered" journal then (or maybe i give a s*** about data2ext then).
Click to expand...
Click to collapse
To me, the main purpose with data2Sd was to get more storage with at least the same amount of performances than the original NAND. I found that, on top of the extra space I have now, I also have a very good performance, roughly the same as NAND on small files and a much better one on bigger files. And I'm not thinking about quadrant score here
Talking about the unmount, if I run an e2fsck -n on the ext2 file while it's in use by the system, I have a report of a few errors (like deleted inode with nodtime, or wrong count of free blocks) But if I shut down the phone and turn in on again, the e2fsck I run at boot reports no errors at all. I might be wrong but my guess is that there is a clean umount done at some stage...
What I am going to do is an other test. You know that when an ext2 partition is not umounted properly, a flag is activated and this ext2 partition must be checked, regardless of the number of mounts done before running a check. This flag can be check by running a tune2fs -l on the partition before mounting it. It is reported as well by the system that the partition hasn't been unmounted properly when you try to mount it and that it should be checked .
So If i turn off my phone, restart in recovery mode, run a tune2fs -l on the ext2 file or mount it manually, I should be able to see if the partition has been unmounted by the system or not before the actual reboot.
I'll report the results and let you know if I'm wrong
OK
I've just turned off my phone. rebooted in recovery, mounted the 2nd FAT32 partition and run a tune2fs -l ext2 (that's the name of my ext2 file mounted via a loop device over /data)
Here is the result:
Code:
tune2fs 1.40.8 (13-Mar-2008)
Filesystem volume name: userdata
Last mounted on: /data
Filesystem UUID: 296f98d0-21e8-48b6-82ac-6c94c4edf28d
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: ext_attr dir_index filetype sparse_super
Filesystem flags: unsigned_directory_hash
Default mount options: (none)
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 60800
Block count: 243056
Reserved block count: 0
Free blocks: 168874
Free inodes: 57516
First block: 0
Block size: 4096
Fragment size: 4096
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 7600
Inode blocks per group: 475
Filesystem created: Tue Dec 7 15:00:51 2010
Last mount time: Thu Dec 9 17:40:16 2010
Last write time: Thu Dec 9 21:16:43 2010
Mount count: 1
Maximum mount count: 21
Last checked: Thu Dec 9 17:40:10 2010
Check interval: 15552000 (6 months)
Next check after: Tue Jun 7 17:40:10 2011
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Default directory hash: half_md4
Directory Hash Seed: 8ff9238f-aef7-48a7-85e1-7d2d45b9e809
You can see that it's reporting that the system is clean. If the ext2 partition wasn't cleanly unmounted by the system at shutdown, it would never report as being clean.
Obviously, if I check the state now that, after booting to android, the FS is mounted over /data, it is reported as being unclean.
It's reporting 1 as mount count because I'm forcing an fsck on boot anyway.
This doesn't mean that I will never get errors tho. I even have some errors from time to time when I reboot my linux home server
melethron said:
-No cache will slowdown write on small files heavily
-Without cache every other process has to wait if some writing is done (lags).
-Much more wear for the sd since small files aren't cached
Using ext2 with sync isn't an option for me. Either i get ext2 with a proper unmount to work or i'll use Ext4 with an "ordered" journal then (or maybe i give a s*** about data2ext then).
Click to expand...
Click to collapse
Remember that there is no writeback cache (AFAIK) with YAFFS2
But I should try with sync off and see if the system is still "clean" after a shutdown. If the systems unmounts ext2 properly, then the cache should be flushed by the system before unmounting the filesystem.
sibere said:
OK
I've just turned off my phone. rebooted in recovery, mounted the 2nd FAT32 partition and run a tune2fs -l ext2 (that's the name of my ext2 file mounted via a loop device over /data)
You can see that it's reporting that the system is clean. If the ext2 partition wasn't cleanly unmounted by the system at shutdown, it would never report as being clean.
Obviously, if I check the state now that, after booting to android, the FS is mounted over /data, it is reported as being unclean.
It's reporting 1 as mount count because I'm forcing an fsck on boot anyway.
This doesn't mean that I will never get errors tho. I even have some errors from time to time when I reboot my linux home server
Click to expand...
Click to collapse
You are right about the "clean" flag being set while unmounted. But you forgot one thing. The "clean" flag must be cleared when the partition is mounted. You should check if it as also reported while it IS mounted .... if so mount doesn't write proberly to the superblock. I would do this myself but im on ext4 and afaik it isn't cleared on mount then. For me this far it shows also "clean" when it is mounted.
My guess that mount doesn't write the superblock proberly is also supported by the fact that your and my mount count both shows 1. This could be a coincidince (chance for this is 0,147928994083 %) but could also support my assumption.
So check again while you mounted your system.
EDIT: I completly agree with you that data2ext is about space. Considering speed i also expirienced that reading larger amounts of data from data/data is faster with data2ext. But i also expirienced some slowdown sometimes on ext 4. It was better on ext2 and with that im really fine.
Remount done: Mount count still 1. I bet you will also get clean when you mount your ext.
melethron said:
Since i'm not really expirenced in scripting on either linux or android i wanted to ask if a script in "init.d/rc0.d" (+"init.d/rc6.d" for reboot) would be possible? I could write one but i don't know if this would be executed and i actually don't know how i could check if it works (i think logcat would be shutdown before this is done).
Edit: At least if rc0.d scripts are run BEFORE logcat stops it doesn't work. Logcat log is empty if i "grep test" an "echo "test"" script.
Need help. Someone ...
Click to expand...
Click to collapse
i think that won't work with rc.0 as init.d script execution is initiated in
init.rc only for "before booting", its not as a "normal" linux init system
# Execute files in /etc/init.d before booting
service sysinit /system/bin/logwrapper /system/xbin/busybox run-parts /system/etc/init.d
disabled
oneshot
i wonder if a shutdown.rc could be populated, there is a shutdown.bravo.rc but its empty
for init-handling, in the kernel source its in system/core/init
but im not fit with c/c++ to look into
maybe the init binary would have to be modified by a kernel dev to enable shutdown.rc / also possible that htc has motified it to not to be used.
woti23 said:
i think that won't work with rc.0 as init.d script execution is initiated in
init.rc only for "before booting", its not as a "normal" linux init system
# Execute files in /etc/init.d before booting
service sysinit /system/bin/logwrapper /system/xbin/busybox run-parts /system/etc/init.d
disabled
oneshot
i wonder if a shutdown.rc could be populated, there is a shutdown.bravo.rc but its empty
for init-handling, in the kernel source its in system/core/init
but im not fit with c/c++ to look into
maybe the init binary would have to be modified by a kernel dev to enable shutdown.rc / also possible that htc has motified it to not to be used.
Click to expand...
Click to collapse
This would have been to easy ....
Well maybe some Kernel Dev will look into this.... coutts, sibere, anyone ... can you help ?
Btw: i still wonder why /system/bin/shutdown is present in ROMs if it's not used ....
melethron said:
This would have been to easy ....
Well maybe some Kernel Dev will look into this.... coutts, sibere, anyone ... can you help ?
Btw: i still wonder why /system/bin/shutdown is present in ROMs if it's not used ....
Click to expand...
Click to collapse
this works for the script that should be executed part
/system/bin/logwrapper /system/xbin/busybox run-parts /system/etc/shutdown.d
runs every script which is in /system/etc/shutdown.d
if you create /system/etc/shutdown.d before
and put one or more executable script/s that do something in
melethron said:
You are right about the "clean" flag being set while unmounted. But you forgot one thing. The "clean" flag must be cleared when the partition is mounted. You should check if it as also reported while it IS mounted .... if so mount doesn't write proberly to the superblock. I would do this myself but im on ext4 and afaik it isn't cleared on mount then. For me this far it shows also "clean" when it is mounted.
My guess that mount doesn't write the superblock proberly is also supported by the fact that your and my mount count both shows 1. This could be a coincidince (chance for this is 0,147928994083 %) but could also support my assumption.
So check again while you mounted your system.
EDIT: I completly agree with you that data2ext is about space. Considering speed i also expirienced that reading larger amounts of data from data/data is faster with data2ext. But i also expirienced some slowdown sometimes on ext 4. It was better on ext2 and with that im really fine.
Remount done: Mount count still 1. I bet you will also get clean when you mount your ext.
Click to expand...
Click to collapse
Sorry mate, but, like I wrote in my previous post, it shows unclean when mounted.
Sent from my HTC Desire using XDA App
sibere said:
Sorry mate, but, like I wrote in my previous post, it shows unclean when mounted.
Sent from my HTC Desire using XDA App
Click to expand...
Click to collapse
ROFL! I should learn to read proberly:
Obviously, if I check the state now that, after booting to android, the FS is mounted over /data, it is reported as being unclean.
Click to expand...
Click to collapse
Well thats actually good news thanks for helping me reading. ^^
Well so this isn't a problem. Now its time for ext4 (no loop) without journal mounted to data. About the loopdevice: you might wanna read what ownhere has to say about loop.
melethron said:
If it's not called do you see any possibility to use "Vold" process? Cause it does the unmounting:
Code:
I/Vold ( 145): /mnt/secure/staging/.android_secure sucessfully unmounted
I/Vold ( 145): /mnt/secure/asec sucessfully unmounted
I/Vold ( 145): /mnt/secure/staging sucessfully unmounted
I/Vold ( 145): /mnt/sdcard unmounted sucessfully
D/Vold ( 145): Volume sdcard state changing 5 (Unmounting) -> 1 (Idle-Unmounted)
Click to expand...
Click to collapse
http://android.git.kernel.org/?p=pl...2af4c72427ad069245d0aa572;hb=refs/heads/froyo
Some interesting stuff in this code here
coutts99 said:
http://android.git.kernel.org/?p=pl...2af4c72427ad069245d0aa572;hb=refs/heads/froyo
Some interesting stuff in this code here
Click to expand...
Click to collapse
i'm running this now on btrfs partition
/dev/block/mmcblk0p6** on /system/sd type btrfs (rw,relatime,ssd,noacl)
/dev/block/mmcblk0p6 5.2G 1.3G 3.9G 26% /system/sd
tmpfs 85.8M 24.0M 61.8M 28% /cache
a2sd btrfs *
d2sd btrfs *
dalvik-cache in /data mtd
cache in ram 90M
* without loop mounted img filesystem
** logical partition on extented partition
woti23 said:
i'm running this now on btrfs partition
/dev/block/mmcblk0p6** on /system/sd type btrfs (rw,relatime,ssd,noacl)
/dev/block/mmcblk0p6 5.2G 1.3G 3.9G 26% /system/sd
tmpfs 85.8M 24.0M 61.8M 28% /cache
a2sd btrfs *
d2sd btrfs *
dalvik-cache in /data mtd
cache in ram 90M
* without loop mounted img filesystem
** logical partition on extented partition
Click to expand...
Click to collapse
Running what now?
conventional (not froyo app2sd) a2sd + data2sd both on btrfs without loopmounted filesystem files
/data/dalvik-cache left in nand
/cache tmpfs in RAM
btrfs instead of ext4
the g330 comes with a reasonable storage. But there is not enough space for apps on /data. The internal sd-card got a lot of space. resizing /data (part. 18) may be critical and requires another recovery image. So my idea is to log in the phone, start fdisk /dev/block/mmcblk0, delete internal sd-card partition (19), then create a e.g. 1 GB partition with ext4, which I will mount on /data/app, and give the rest to a new partition 20 for internal sd-card.
I think this approach is more fail-save and can be done quite fast. I have to change just init.rc to add one mount and vold.fstab. Has somebody tried this?
yes, i know, the dalvik-cache and /data/data will still load the /data partition, and app2sd would save the same space from /data. But app2sd needs one mount for each app (at least in GB), so booting takes very long time and I have to wait until I can launch an app.
I read sometimes, the kernel get the offsets of the partitions of flash as parameters when booted - so some offsets would be wrong when I change the partion table. This would cause to fail mount /data/app - what about this?
rregn said:
the g330 comes with a reasonable storage. But there is not enough space for apps on /data. The internal sd-card got a lot of space. resizing /data (part. 18) may be critical and requires another recovery image. So my idea is to log in the phone, start fdisk /dev/block/mmcblk0, delete internal sd-card partition (19), then create a e.g. 1 GB partition with ext4, which I will mount on /data/app, and give the rest to a new partition 20 for internal sd-card.
I think this approach is more fail-save and can be done quite fast. I have to change just init.rc to add one mount and vold.fstab. Has somebody tried this?
yes, i know, the dalvik-cache and /data/data will still load the /data partition, and app2sd would save the same space from /data. But app2sd needs one mount for each app (at least in GB), so booting takes very long time and I have to wait until I can launch an app.
I read sometimes, the kernel get the offsets of the partitions of flash as parameters when booted - so some offsets would be wrong when I change the partion table. This would cause to fail mount /data/app - what about this?
Click to expand...
Click to collapse
I tried this and it works
its for g300 but it works on g330
http://www.htcmania.com/showthread.php?t=428466
sorry, its in spanish haha use the google tranlator
xals1997 said:
I tried this and it works
its for g300 but it works on g330
http://www.htcmania.com/showthread.php?t=428466
sorry, its in spanish haha use the google tranlator
Click to expand...
Click to collapse
Did i get the idea? You use link2SD (from Bülent Akpinar) , but instead of using a 2nd partition of the external SD-card with ext2, you use the internal SD-card for link2SD?
But i heard that link2SD need a ext2/3 partition? Also, in my version of link2SD there is:
mount -t ext2 -o rw /dev/block/vold/179:2 ...
btw. how is /system/etc/install-recovery.sh triggered
I'm wanting to write some edify code to wipe data, dalvik and cache. I think i've got the right idea for data and dalvik, but I'm not certain on cache.
Here's my following code for data and dalvik wipe. Is this the standard for wiping data? Do i need to delete everything from data and not just in the app directory?
Code:
mount("ext4", "EMMC", "/dev/block/mmcblk0p37", "/data");
delete_recursive("/data/app");
delete_recursive("/data/dalvik-cache");
unmount("/data");
Also, i'm going to assume i can mount the cache, but i didn't know the block to mount it.
Any help would be greatly appreciated.
Edit: Thanks to this post, i was able to figure out the block i needed for cache. I would still like to know if this is the proper way of "wiping" the data, cache or dalvik-cache. Should i be formatting instead?
I'm not very familiar with edify, so I may be wrong, however I'll try to help by pointing some issues you may find when investigating this subject.
First look on the code above ... In general, it seems to be ok. Btw I can see that you are not trying to wipe /data but /data/app only...
To fully wipe data partition you shall run delete_recursive("/data"); and after that no additional dalvik-cache wipe will be necessary, as it lies on data so it will be deleted along with it.
Instead of recursive files deletion you may try format command or even some variation of mke2fs... it will create completely new filesystem instead of performing large amounts of delete i/o operations on the old one, along with not deleting filesystem stats, etc.
Hovewer, you have to know that running delete_recursive("/data"); or even format("/data") or something similiar seems to be not the best idea - be aware that real location of files from /sdcard is /data/media which is then bound with FUSE driver to /sdcard during the boot, so it acts like an sd memory BUT it still lies along with all your "regular" data files on /data partition. Doing such a recursive deletion will result in losing not only files from /data, but also from /data/media = /sdcard, which is probably not the thing we want to happen ;]
You may want to figure out how to avoid this, as you may lose the data which you didn't want to lose (for example: nandroid backups, if you keep them on /sdcard)! I personally don't know the exact solution and don't have time and possibility to figure it out at the moment
Also, please be aware that Android has the "wipe" command built-in, put "wipe" in terminal emulator to find out the syntax. I am not sure but it may avoid the sdcard when wiping automatically, as it is native android tool and it may be adapted for Android's file stricture.
Last but not least, you can find out device-partition pairs by inputting such a command via terminal or adb shell (seeking for a device name which is mounted as /cache in example below):
Code:
cat /proc/mounts | grep cache
esgie said:
I'm not very familiar with edify, so I may be wrong, however I'll try to help by pointing some issues you may find when investigating this subject.
First look on the code above ... In general, it seems to be ok. Btw I can see that you are not trying to wipe /data but /data/app only...
To fully wipe data partition you shall run delete_recursive("/data"); and after that no additional dalvik-cache wipe will be necessary, as it lies on data so it will be deleted along with it.
Instead of recursive files deletion you may try format command or even some variation of mke2fs... it will create completely new filesystem instead of performing large amounts of delete i/o operations on the old one, along with not deleting filesystem stats, etc.
Hovewer, you have to know that running delete_recursive("/data"); or even format("/data") or something similiar seems to be not the best idea - be aware that real location of files from /sdcard is /data/media which is then bound with FUSE driver to /sdcard during the boot, so it acts like an sd memory BUT it still lies along with all your "regular" data files on /data partition. Doing such a recursive deletion will result in losing not only files from /data, but also from /data/media = /sdcard, which is probably not the thing we want to happen ;]
You may want to figure out how to avoid this, as you may lose the data which you didn't want to lose (for example: nandroid backups, if you keep them on /sdcard)! I personally don't know the exact solution and don't have time and possibility to figure it out at the moment
Also, please be aware that Android has the "wipe" command built-in, put "wipe" in terminal emulator to find out the syntax. I am not sure but it may avoid the sdcard when wiping automatically, as it is native android tool and it may be adapted for Android's file stricture.
Last but not least, you can find out device-partition pairs by inputting such a command via terminal or adb shell (seeking for a device name which is mounted as /cache in example below):
Code:
cat /proc/mounts | grep cache
Click to expand...
Click to collapse
Thanks a bunch! I didn't even think about the sdcard getting wiped...
=Death259;48255914]Thanks a bunch! I didn't even think about the sdcard getting wiped...
Click to expand...
Click to collapse
What you can do is extract and call a bash script and recursively remove all content from /data excliding the media folder (sdcard)
Also dalvik is in /data already so wiping data automatically wipes dalvik
once i got the pixel 3 xl i got to tinkering with it, rooting, twrp, a few hacks and tweaks i do to all my phones to see if i could get more performance out of it
here are my findings coming from a oneplus 6
1. exremely poor ram management compared to my op6, redraws, apps reloading, slower app loading compared to my tweaked op6.
2. if you run decrypted data you can no longer register a fingerprint, the option is completely gone, and the screen pin can not be changed once set in settings, to change it you must delete the locksetting.db file in /data/system
3. sometimes running slow, not sure if its kernel related (i would like to think so because it sometimes becomes speedy out of nowhere) opening apps, switching apps, etc etc is slower than my op6
4. no journaling, the first phone i have ever seen to not run a journal on the file system partition, this has always been my #1 tweak when i unlock a BL - great move by google
5. notifications not appearing for google pay - or are delayed by tens of minutes eventhough the payment has gone through, i have done all the tweaks to disable battery management etc but still no go
currently i am experimenting /data partition formatted to EXT4 (if possible) since F2FS is running the encryption of a secondary partition (i believe this was a drawback of f2fs back in the day)
tweaks i have used:
editing the fstab to remove unneccessary options (i.e barrier, discard, background_gc, blockvalidity, etc)
there exists a journal on the /metadata partition - i have removed it with no consequence
edit:
i can not run /data as EXT4 - even after modifying the fstab and changing to ext4 in twrp - it returns with a corrupt error and only option is to try again or format data.
if anyone has any ideas on how to get it successfully working
yet to find a way on how to boot with /data as EXT4
keep failing boot once i edit the fstab to include EXT4 on the /data partition, and tells me to format my data before i can boot into OS
if anyone has any ideas on how to format /data as EXT4 please let me know
i have suspicions that EXT4 will run better on the /data partition
Is there any way to prepare a Gapps like package with additional apps of choice (any app i want to be installed) and install them after ROM into system partition?
If i install a debloated Gapps i end up with 3/4 of unused system partition which will not be used in the future-it is a space wasted. resizing partitons is dangerous if i have to use backups. If it would be possible to install apps of choice into the system partition then i could use up system partition space and use userdata space for other stuff. Of course app updates of apps installed into system partition should be installed/stored in system partition too.
Thank you
Personally never would abuse /system partition to store user-apps there.
xXx yYy said:
Personally never would abuse /system partition to store user-apps there.
Click to expand...
Click to collapse
Why if 3/4 of space is unused? Could you let me know if you are familiar with dangers of it? thanks
Never encountered or heard of that 3/4 of storage space under /system is unused. My experince is that only some 100KB are free for further use ( updates ).
xXx yYy said:
Never encountered or heard of that 3/4 of storage space under /system is unused. My experince is that only some 100KB are free for further use ( updates ).
Click to expand...
Click to collapse
Isnt this system space on the screenshot system partition? Let me know if i am wrong. thank you
If phone's Android is rooted and its /system partition is mounted as RW then apply the du command in Android's terminal to get the disk space memory utilized by files in /system partition.
To get the unused disk space memory in /system apply the df command.