I recently switched from ext4 to f2fs file system on all partitions. After that I flashed omni's nightly in order to update and noticed that my /system partition was reverted to ext4 due to the reformat while flashing.
I think it would be helpful if the OmniROM zips contained some sort of check routine, so the file system type could be preserved and future updates are possible without the whole process of backing up, reformatting and restoring again.
I know the file system type depends on kernel support and also the custom recovery must be able to work with it, but I think it's the users responsibility anyway. I mean, either you know what you're doing or you leave it alone, right?
I hope this gets realised or there is some compromise. Currently I'm using latest OmniROM with Devil's recovery and kernel without dualboot.
Sent from my GT-N7100 using Tapatalk
klenamenis said:
I recently switched from ext4 to f2fs file system on all partitions. After that I flashed omni's nightly in order to update and noticed that my /system partition was reverted to ext4 due to the reformat while flashing.
I think it would be helpful if the OmniROM zips contained some sort of check routine, so the file system type could be preserved and future updates are possible without the whole process of backing up, reformatting and restoring again.
I know the file system type depends on kernel support and also the custom recovery must be able to work with it, but I think it's the users responsibility anyway. I mean, either you know what you're doing or you leave it alone, right?
I hope this gets realised or there is some compromise. Currently I'm using latest OmniROM with Devil's recovery and kernel without dualboot.
Sent from my GT-N7100 using Tapatalk
Click to expand...
Click to collapse
That's a lot of work and means maintainers then have to officially support testing two different filesystem configurations.
f2fs on /system is pointless since /system is only written to when updating. Even Motorola, one of the first OEMs to actually use f2fs, only uses it for /data
For devices that don't already use it, I'm not transitioning them. It doesn't offer enough performance benefits to compensate for its piss-poor data integrity. A filesystem that can get corrupted to the point of needing a complete format just to get its fsck to run without crashing (this has already happened to me TWICE on the Moto G) is just not ready for production.
Entropy512 said:
f2fs on /system is pointless since /system is only written to when updating. Even Motorola, one of the first OEMs to actually use f2fs, only uses it for /data
For devices that don't already use it, I'm not transitioning them. It doesn't offer enough performance benefits to compensate for its piss-poor data integrity. A filesystem that can get corrupted to the point of needing a complete format just to get its fsck to run without crashing (this has already happened to me TWICE on the Moto G) is just not ready for production.
Click to expand...
Click to collapse
Well, pretty much makes sense. I just updated and let system be ext4 formatted from now on.
Sent from my GT-N7100 using Tapatalk
Related
Hi all,
First of all I would like to say that this is purely not my work.All thanks goes to Fi***o(Guess him...).
Ok to the matter.You all know that most of the superbricks are caused because of the wipe done in recovery.It actually causes an I/O error which causes the /data partition in eMMC to get unrepairable.Even Odin,heimdall,shell....Nothin can fix it.And without /data partition your phone cannot boot.Since only the /data partition is damaged,you can use download mode and flash any kernel and even enter recovery sometimes.So explanation part is over.
Now to make our phone to boot up we must find a way to get /data partition working.But how can we?You know,there is a partition called /preload (hidden.img) which is always empty and almost not at all used and its size is 512 MB.So we are actually wasting 512 MB.A kernel only controlls where to mount what partition.So If we could make a kernel which would swap /data and /preload,/data will be mounted at /preload location and it will be fine and working and our phone will be able boot and run normally.
So does it only have advantages?Surely no.It has its own disadvantages too...
1.Your /data partition is shrinked to 512 MB
2.You should only stay on custom roms.You cannot flash a stock rom or anything through odin except kernels....
3.You can flash this kernel only through PC odin which means yellow triangle and increase counter.
But you can use CWM to flash any custom roms because it doesnt check for /preload but stock rom does....
And as I said earlier this is ain't my work but dont feel shy to press that thanks button if you like it....
I think it is Ficeto (DarkyROM kernel dev) who did this first. I remember someone posting something about this previously, but was probably missed.
EDIT: Worth it for people who don't have the $200 odd dollars in the meantime for a new MOBO
I actually do not recommend any custom ROMs! as they are all deodexed and that means that they store their odex(dex) files in /data/dalvik-cache which further uses more /data space.
What you can flash is: custom factoryfs.img(less apps and added CSC), empty hidden.img, custom zImage(that is made to swap /data and /preload) and boot loaders(boot.bin, Sbl.bin and param.lfs).
Do not flash stock cache.img or data.img!
With taking all that in consideration, my Note is now running LPF with LPY CSC
hkgrob said:
I think it is Ficeto (DarkyROM kernel dev) who did this first. I remember someone posting something about this previously, but was probably missed.
EDIT: Worth it for people who don't have the $200 odd dollars in the meantime for a new MOBO
Click to expand...
Click to collapse
I already gave a vague idea in someother thread.But I'm not use it was my post or not...
vijai2011 said:
Hi all,
First of all I would like to say that this is purely not my work.All thanks goes to Fi***o(Guess him...).
Ok to the matter.You all know that most of the superbricks are caused because of the wipe done in recovery.It actually causes an I/O error which causes the /data partition in eMMC to get unrepairable.Even Odin,heimdall,shell....Nothin can fix it.And without /data partition your phone cannot boot.Since only the /data partition is damaged,you can use download mode and flash any kernel and even enter recovery sometimes.So explanation part is over.
Now to make our phone to boot up we must find a way to get /data partition working.But how can we?You know,there is a partition called /preload (hidden.img) which is always empty and almost not at all used and its size is 512 MB.So we are actually wasting 512 MB.A kernel only controlls where to mount what partition.So If we could make a kernel which would swap /data and /preload,/data will be mounted at /preload location and it will be fine and working and our phone will be able boot and run normally.
So does it only have advantages?Surely no.It has its own disadvantages too...
1.Your /data partition is shrinked to 512 MB
2.You should only stay on custom roms.You cannot flash a stock rom or anything through odin except kernels....
3.You can flash this kernel only through PC odin which means yellow triangle and increase counter.
But you can use CWM to flash any custom roms because it doesnt check for /preload but stock rom does....
And as I said earlier this is ain't my work but dont feel shy to press that thanks button if you like it....
Click to expand...
Click to collapse
Hmmm I actually had a simillar idea couple of days ago ,but not the preload parttion ,I thought that someone could mount data and system partitions on any other partitions ,like internal sdcard (the user accessable space) and then move the actual user accessable Sdcard to external storage ?
but I don't think it's the kernel alone that can do this ,but rather a modified .pit file (to repartition the sdcard) along with a modified kernel?
just thinking out loud here and could be just mumbling and totally wrong ,but I hope it gives the devs a starting point to help those poor superbricked people.
MR.change said:
Hmmm I actually had a simillar idea couple of days ago ,but not the preload parttion ,I thought that someone could mount data and system partitions on any other partitions ,like internal sdcard (the user accessable space) and then move the actual user accessable Sdcard to external storage ?
but I don't think it's the kernel alone can do this ,but rather a modified .pit file along with a modified kernel?
just thinking out loud here , hope it gives the devs a starting point to help those poor superbricked people.
Click to expand...
Click to collapse
Do you ever use a pit file in flashing custom roms through CWM or when flashing kernel through PC odin???As I said earlier you cannot flash any rom through odin except a kernel I guess.I'm not a superbrick owner.
But yeah what you said should also work but its very time consuming and confusing.
MR.change said:
Hmmm I actually had a simillar idea couple of days ago ,but not the preload parttion ,I thought that someone could mount data and system partitions on any other partitions ,like internal sdcard (the user accessable space) and then move the actual user accessable Sdcard to external storage ?
but I don't think it's the kernel alone can do this ,but rather a modified .pit file along with a modified kernel?
just thinking out loud here , hope it gives the devs a starting point to help those poor superbricked people.
Click to expand...
Click to collapse
much simpler to just use /preload most is still as it should be and only 3 lines need changing in a stock kernel(initramfs) for it to work. cwm requires another line changed and that is it.
I can provide a working GGB and LPF kernels (no cwm in LPF)
its one of my ideas.. relocating the partition to be used...
vijai2011 said:
Do you ever use a pit file in flashing custom roms through CWM or when flashing kernel through PC odin???As I said earlier you cannot flash any rom through odin except a kernel I guess.I'm not a superbrick owner.
But yeah what you said should also work but its very time consuming and confusing.
Click to expand...
Click to collapse
No not through CWM but PC ODIN ,and yes many superbricked people could flash .pit file successfully from pc odin.
ficeto said:
much simpler to just use /preload most is still as it should be and only 3 lines need changing in a stock kernel(initramfs) for it to work. cwm requires another line changed and that is it.
I can provide a working GGB and LPF kernels (no cwm in LPF)
Click to expand...
Click to collapse
yes I understand that my method is much harder ,but like I said I'm no dev and this just an idea that I had couple of days ago.
but there is some methodology to my madness:
the preload partition is only 512 mb ,thus very small for some ROMs .
my method (if doable at all) should give users much larger ROM space ,as they can use the SDcard which is 12 GBs of space.
ficeto said:
much simpler to just use /preload most is still as it should be and only 3 lines need changing in a stock kernel(initramfs) for it to work. cwm requires another line changed and that is it.
I can provide a working GGB and LPF kernels (no cwm in LPF)
Click to expand...
Click to collapse
I don't have a bricked note, but that's worth a thanks for sure. If you could share, I am sure a bunch of people will be doing random cartwheels.
Then again, someone will probably asked if they can flash it here, or there, or everywhere!
hkgrob said:
I don't have a bricked note, but that's worth a thanks for sure. If you could share, I am sure a bunch of people will be doing random cartwheels.
Then again, someone will probably asked if they can flash it here, or there, or everywhere!
Click to expand...
Click to collapse
the problem is that that kernel should be used correctly.Its not like cf-root,abyss kernel.If you flash on a note in good condition,you might have some problems...
I thought /data has user data and ROM is flashed onto a different partition, no?
anilisanil said:
I thought /data has user data and ROM is flashed onto a different partition, no?
Click to expand...
Click to collapse
Yeah partially right.A rom requires both /system and /data.
Good work.
Once the bricked note is up nd running, and rooted, ain't it possible to write some lowlevel partition and format utility to repair the original /data portion of EMMC ?
friedje said:
Good work.
Once the bricked note is up nd running, and rooted, ain't it possible to write some lowlevel partition and format utility to repair the original /data portion of EMMC ?
Click to expand...
Click to collapse
Nope.Not at all possible.The partition becomes completely inaccessable.
Yes there are low level programs like parted - to repartition.
e2fsck to scan for bad sectors -like scandisk in windows.
format - should be possible -- I have to get help of forest1971 for this.
prabhu1980 said:
Yes there are low level programs like parted - to repartition.
e2fsck to scan for bad sectors -like scandisk in windows.
format - should be possible -- I have to get help of forest1971 for this.
Click to expand...
Click to collapse
Is this correct? I was under the impression that the emmc error was due to incorrect voltages being passed and therefor physically frying the chips, hence the only fix is to replace the chips/mobo?
Sent from my GT-N7000 using xda premium
Ofcourse there are no weird voltages applied. It's still the same chip being programmed by the same program delivering the same voltages.....
Actually the program doesn't set any voltages, it just tells the chipset to put the memory into the 'writing mode'
The most likely problem is that a wrong entry point is being written into the filesystem for the data partition.
I was not able to format it in any way and trust me I tried everything ....
Just found this on the net.
http://mobiletechvideos.mybigcommerce.com/samsung-galaxy-note-jtag-brick-repair/
expensive but less then 200 for a new mobo. maybe somebody wants to try.
I accidentally deleted a folder on my One's internal storage ( "/storage/sdcard0" which is also known as "/sdcard/" and linked to "/storage/emulated/0/" ) yesterday. There have been some documents that were deleted so I tried to recover them.
Here on xda we have a comprehensive guide how to recover internal storage. The problem is that other than SD card based external storage, internal storage is ext4 formatted and not visible to a computer as mass storage (content is transferred via MTP) hence common recovery tools such as testdisk, recuva, r-studio can't search the file system on a low level to recover lost files from an android's internal storage.
The solution to this is to copy over the entire (raw) data partition to your computer where you can proceed to have recovery tools search for your lost data. This can be done via adb. BusyBox and Root is required.
The detailed recovery/imaging process is described here:
http://forum.xda-developers.com/showthread.php?t=2143188
http://forum.xda-developers.com/showthread.php?t=1994705
BusyBox includes the linux "dd" command to create a bit-to-bit image of your data partition and "nc" that is used to pipe the data directly off the phone to your computer so nothing will get overwritten.
The userdata partition on the One is /dev/block/mmcblk0p37 and roughly about 25GB on 32GB Ones or 55GB on a 64GB One in size. It takes some hours to copy it over to your computer (was around 5h for my 64gig variant, 4MB/s avg).
After finishing that, you let multiple recovery tools of your choice work their magic on the huge raw partition backup, just to realize that other than existing data no deleted files are found.
Time to investigate further so I took another One which had the 4.2.2 based ARHD 10.2 installed, factory reset the device and filled it up with data. Then I deleted the whole userdata via my MTP-connected computer and immediately started over the imaging process. A few hours later I hex-edited the partition backup and found that 80% of the partition was zeros. My recovery tools still found existing data in /data/ that obviously have not been touched by me when deleting the "internal storage" through my computer as it is not accessible that way.
From my investigation so far, to me it seems that there is some kind of TRIM'ming or instant garbage collection going on to clean up unused NAND cells which carry previously deleted data. That is what is done on SSDs to maintain write speeds, which is a good thing actually. If that is the case, there would be virtually no chance to recover lost data as it gets wiped/zero'ed immediately.
What I want to find out is whether this behavior is from kernel or hardware, specifically internal flash controller. What are your thoughts?
Hope that helps others a bit.
Most phone NANDS have Trim activated. The HoX however did not, and that's why apps like FSTrim exists, to force a TRIM pass. Greatly smoothed out the random I/O lags even when scrolling through Sense.
If your using elementalx kernel it runs an fstrim command on boot and installs the binary when you flash the kernel ....
Its from an fstrim init.d mod I made for the hox which is being used in that kernel on the m7...
As for fstrim if your not using that kernel, I'm sure unless the fstrim file is in system/bin / xbin htc/Qualcomm arnt using it.
backfromthestorm said:
If your using elementalx kernel it runs an fstrim command on boot and installs the binary when you flash the kernel ....
Its from an fstrim init.d mod I made for the hox which is being used in that kernel on the m7...
As for fstrim if your not using that kernel, I'm sure unless the fstrim file is in system/bin / xbin htc/Qualcomm arnt using it.
Click to expand...
Click to collapse
I checked it and the file is not there. I didn't use elementalx kernel or any non-stock kernel when it happened. I did not reboot the phone before I made the image with dd.
There must be something in the stock kernel or nand controller...
Are the partitions mounted with the discard option?
flar2 said:
Are the partitions mounted with the discard option?
Click to expand...
Click to collapse
Indeed the data partition is mounted with discard. That might explain it. The file system reports free space to the controller immediately which kicks off the cleaning.
Hi all, not so sure if this is repeated question.
I am looking for a faster rom for my phone, wants it to be fast and saves battery. Could you guys provide suggestions?
My Nexus 4 is currently on:-
Rom: Paranoid Android 4.6-Beta6 (Unofficial release, found under development threads)
Kernel: 3.4.104-franco-Kernel-SaberMod-r213.2
File system: Full-F2FS (System, cache, data are in F2FS file system)
Thanks in advanced. ^^
Chroma+Quanta kernel, you can convert /data and /cache to f2fs if you want
voron00 said:
Chroma+Quanta kernel, you can convert /data and /cache to f2fs if you want
Click to expand...
Click to collapse
Will there be performance sacrifice as system partition not F2FS?
I would PM you later on how should I carry out the process. The last time I flashed, I got message prompting me to type a message to access locked storage, but it's actually due to it couldn't access as kernel doesn't support F2FS. Probably I didn't flash F2FS kernel after flashing rom.
ordinarystar said:
Will there be performance sacrifice as system partition not F2FS?
I would PM you later on how should I carry out the process. The last time I flashed, I got message prompting me to type a message to access locked storage, but it's actually due to it couldn't access as kernel doesn't support F2FS. Probably I didn't flash F2FS kernel after flashing rom.
Click to expand...
Click to collapse
There is no big improvement of using F2FS at all. And since /system is read only this is totally not need
And yes, you got storage locked because of kernel without F2FS support.
I was wondering that with TWRP 3.0, it is possible to convert the file system to f2fs. The performance in f2fs seems to be far greater when compared to ext4. Has anyone tried converting the x play to f2fs? If so, what all ROMs are compatible with it?
varounmirchi said:
I was wondering that with TWRP 3.0, it is possible to convert the file system to f2fs. The performance in f2fs seems to be far greater when compared to ext4. Has anyone tried converting the x play to f2fs? If so, what all ROMs are compatible with it?
Click to expand...
Click to collapse
I don't think it's possible to convert a filesystem to another, you'll probably need to format your partition in f2fs, so make a backup first.
Also, note that f2fs is designed to take advantage of nand-based storage. Have a look at http://www.xda-developers.com/f2fs-put-to-the-test-against-ext4/
claudineimatos said:
I don't think it's possible to convert a filesystem to another, you'll probably need to format your partition in f2fs, so make a backup first.
Also, note that f2fs is designed to take advantage of nand-based storage. Have a look at http://www.xda-developers.com/f2fs-put-to-the-test-against-ext4/
Click to expand...
Click to collapse
As far as I know, you do need to format in order to convert. I don't think any kind of conversion tool exists at this point, or may ever exist. I remember reading that there's only really a benefit to making the data partition f2fs (and perhaps the cache as well? I'm pretty tired atm so I can't confirm that.) If so, you should be able to format Data without reinstalling the ROM. Correct me if I'm mistaken!
Be aware that while f2fs is definitely faster, filesystems are relatively simple things that wind themselves into complex knots when put into action. So, despite f2fs being optimized for NAND, it hasn't been thoroughly tested the way EXT4 and others have. You could always run into some issues with data loss or other confusing bugs. Because of this, it's probably also safer to leave the System partition as EXT4, if you even can/would want to make it f2fs.
I'd also like to know if anyone has gotten f2fs working on the Moto X Play, @squid2 has f2fs driver updates listed in the changelog for his kernel, although it may also take support in the ROM to fully implement. Please let us know if you get it running! The performance is significantly faster, and it's also less wear-and-tear on the memory, if I understand correctly.
JohnHorus said:
As far as I know, you do need to format in order to convert. I don't think any kind of conversion tool exists at this point, or may ever exist. I remember reading that there's only really a benefit to making the data partition f2fs (and perhaps the cache as well? I'm pretty tired atm so I can't confirm that.) If so, you should be able to format Data without reinstalling the ROM. Correct me if I'm mistaken!
Be aware that while f2fs is definitely faster, filesystems are relatively simple things that wind themselves into complex knots when put into action. So, despite f2fs being optimized for NAND, it hasn't been thoroughly tested the way EXT4 and others have. You could always run into some issues with data loss or other confusing bugs. Because of this, it's probably also safer to leave the System partition as EXT4, if you even can/would want to make it f2fs.
I'd also like to know if anyone has gotten f2fs working on the Moto X Play, @squid2 has f2fs driver updates listed in the changelog for his kernel, although it may also take support in the ROM to fully implement. Please let us know if you get it running! The performance is significantly faster, and it's also less wear-and-tear on the memory, if I understand correctly.
Click to expand...
Click to collapse
Actually TWRP allows to convert the file system to f2fs (yes by formatting it obviously). Its usually recommended to convert the /data and the /cache partitions for optimum results. I had a Yu Yuphoria before this, and I had converted the file system to f2fs, and the performance was whooping fast.
And I did see that @squid2 has mentioned f2fs support in his kernel (i guess it comes directly from CAF) but I wanted to know which ROMs do support it? So far I don't see "f2fs supported" mentioned in any of the ROMs for our device and thats why I am still on hold.
We're already using f2fs. Even the stock ROM uses f2fs for the userdata partition.
So can we use f2fs with your Kernel and CM13? Data and cache partitions?
squid2 said:
We're already using f2fs. Even the stock ROM uses f2fs for the userdata partition.
Click to expand...
Click to collapse
Cache shows up as ext4 in TWRP, for me at least. Would that benefit from switching to f2fs?
Edit: Tried formatting the cache as f2fs, no boots.
F2fs does use a log, but still, it took up 128MB of the cache partition, seems kinda weird unless the partition actually grows to accomodate that. Maybe I did something wrong, idk.
Why? It's been stuck at 60.5mb used and 1.2GB free according to Diskinfo forever now. Ever since I restored Madvane's unrooted B180 backup & then flashed root with Magisk.
Why does it bother me? Because I have no idea what I'm talking about and I feel like maybe Cache is storing in the Data Partition where I install my apps...? Is it?
Also with 1.2GB free in the Cache parition & 1.2GB free in the System Partition, can I just partition those and make the Data partition bigger for more available Internal Storage for apps and stuff? I mean I have external storage as default location but so many files still get installed on internal and I'd like to expand that if I could alter these partitions.
Anybody done that before or can answer my questions? Thanks! Images attached
Anyone ?
I have not read of anyone here repartitioning internal storage. I don't think it's as simple as repartitioning a PC hard drive with a GUI tool.
Do you have any tools in mind to do this repartitioning? I think it would be a highly risky operation, so be sure to make full backups and note all the original settings of existing partitions before repartitioning.
You can Google threads on people repartitioning internal storage for other phones, but note the ones who ran into problems and bricked their phones.
I wouldn't mess with the partition sizes, personally.. in theory it works, but it can trigger some arcane safeguards added by oems.
Try wiping the cache partition in twrp..? Could have gotten bugged, which would throw an error and require reformatting
Is there any indication of a problem with the cache partition?
It's biggest usage would be to download an OTA file, so unless that's happening, I would expect cache partition to remain remain mostly empty as OP reported. Probably what's in there is TWRP or stock recovery logs - you can confirm with a root file manager.
Wiping the cache partition as suggested won't harm anything and it would be interesting to know what it's reported usage is after wipe and reboot.
divineBliss said:
Is there any indication of a problem with the cache partition?
It's biggest usage would be to download an OTA file, so unless that's happening, I would expect cache partition to remain remain mostly empty as OP reported. Probably what's in there is TWRP or stock recovery logs - you can confirm with a root file manager.
Wiping the cache partition as suggested won't harm anything and it would be interesting to know what it's reported usage is after wipe and reboot.
Click to expand...
Click to collapse
I guess that was my question too. If there was any idication of an issue here. Seeing that free space I'd like to have it though.
On another note. There's no indication of anything being wrong with my Data partition but I formatted it to ext4 back when I bricked my phone in a hope it would fix something. But it seems fine. IDK what they default partition type was.
My data partition is ext4, which I believe is the stock default type.
divineBliss said:
My data partition is ext4, which I believe is the stock default type.
Click to expand...
Click to collapse
Thanks man you've been allot of help. Have you tried L-Speed? I'm thinking about trying it. I do have Kernel Auditiur installed. Don't use it.
Nothing is broke but thought about trying L-Speed.
Never heard of it. If you try it, let us know what you think.
WifiGhost said:
Thanks man you've been allot of help. Have you tried L-Speed? I'm thinking about trying it. I do have Kernel Auditiur installed. Don't use it.
Nothing is broke but thought about trying L-Speed.
Click to expand...
Click to collapse
divineBliss said:
Never heard of it. If you try it, let us know what you think.
Click to expand...
Click to collapse
I just tried it seems like a nice and easy way to tweak performance or battery.
I prefer kernel adiuator myself.. L Speed has too many generic settings which do next to nothing for actual performance, reminiscent of the many garbage tweak programs that have been out there for years. K.A. allowed for better control of the cpu governor settings, which allowed me to negate some of the impact of emui's 'battery optimization'. A little bit of entropy tweaking on top of that, and I no longer experience nearly the amount of choppiness