Related
Hello,
Why isnt it possible to use SDCRAM as sort of RAM in android? same as VISA/7 Using ReadyBoost to expand the ram with an USB disk on keys?
thanks!
Why would you want that?
since you only use flash based memory anyway: that's called swaping
And is Swap enabled in all froyo roms today?
rommark said:
And is Swap enabled in all froyo roms today?
Click to expand...
Click to collapse
But why would you need it? You have 512MB of RAM, with a clean boot you have around 200-220MB of it free for whatever you want to do with it. Not enough for you?
martino2k6 said:
But why would you need it? You have 512MB of RAM, with a clean boot you have around 200-220MB of it free for whatever you want to do with it. Not enough for you?
Click to expand...
Click to collapse
won't heavy 3d games eat that?
rommark said:
won't heavy 3d games eat that?
Click to expand...
Click to collapse
No. Smartphones =/= PCs. And if you are really out of space for a short amount of time, unneeded processes get killed automatically. Swap was only really needed on the G1 but definitely not on the Desire.
rommark said:
won't heavy 3d games eat that?
Click to expand...
Click to collapse
No, that's a bit too much even for a game... unless the code has memory leaks. With so much RAM it'd make more sense to use ramdisk (but who knows for what good use)
martino2k6 said:
No, that's a bit too much even for a game... unless the code has memory leaks. With so much RAM it'd make more sense to use ramdisk (but who knows for what good use)
Click to expand...
Click to collapse
RamDisk could be insane for 3d gaming as then the textures would have fast extraction means less delay in rendering....
What Readyboost is NOT
Hey folks. I've only recently discovered Readyboost as I'm primarily a Linux guy. I got all hot and bothered about it immediately as well as it is (despite Microsofts constant onslaught of horrific failures) an absolutely brilliant and elegant technology/idea.
HOWEVER!!!
Nearly everyone is confused about what RB actually does, so I thought I'd take a minute to explain.
ReadyBoost is NOT swap. NOT SWAP!, not swap.
Swap is not something to get excited about, it is a last resort for when you're out of RAM and it's excruciatingly slow. In the land of IT, one of the first things we check for when a server is experiencing horrible performance, is "IS THIS MACHINE SWAPPING". Everyone's gotta learn that swap, while it is more useful than "not enough memory" it is nor more useful than utilizing the memory you already have, and it will always result in poor performance.
ReadyBoost is an additional disc cache for small, non-sequential reads/writes. It works with your existing FS cache but is faster in some cases because FLASH has a much lower seek time. Most FLASH chips have a seek time of <1ms while most rotational discs have a seek time of around 8ms. This adds up on a large number of small non-sequential r/w.
ReadyBoost takes any caching operations which fit it's strength profile (small, non-sequential) and offloads them to your FLASH device. This can increase load speed of some files/application dramatically (2-20x faster).
So, when someone asks you if they can use Readyboost because they don't have enough memory, please, take a moment to explain that RB is not swap, but is in fact a supplementary disc cache for small, non-sequential reads and writes.
That said, I haven't had time to dig into the question of whether or not RB would benefit Linux FS's.
I know this is a really old thread but I just wanted to put my two cents in. Memory boosting apps like ReadyBoost do have a viable purpose. That is keeping older hardware viable as minimum specs increase. There is an Android app that is equivilant to ReadyBoost called Roehsoft RAM Expander. There are mixed reviews for its performance but that is to be expected. If this app helps my aging 8227_Demo head unit work well enough for me to not replace it I will update this post.
First of all sorry if this is in the wrong section, i thought it might go in discussion but its more a question:
I own an HTC Desire but was recently looking on the net about the Samsung Galaxy S as a friend of mine was after an android phone, and discovered this article on BriefMobile.com:
Samsung Captivate Reaches New Speeds
So, remember when we told you that Android developers were working on a fix for the Samsung Galaxy S’ I/O read-write problems? Remember when we said that we could see these Galaxy S phones reaching 3000+ Quadrant benchmark scores in no time? Well, buckle up folks, because we’re well on our way.
Today, users tried out a new modification for the Samsung Captivate that “creates a VIRTUAL EXT2 filesystem inside the stock RFS filesystem on the internal SD card” of the Captivate. The so-called lag fix boosts I/O scores by around 800% according to the Quadrant benchmarking application.
And, just days ago, users over at XDA-Developers saw the first overclocked kernel for the Captivate. Made by developer AJerman, this 1.2 GHz overclock kernel will boost your performance by around 15-20%.
With these two fixes in place, we saw consistent 2500+ Quadrant scores, far surpassing the capabilities of any other phone to date. The Motorola Droid X has recently been overclocked to allow for ~1350 scores on Quadrant.
Unfortunately, the overclock kernel contains one major bug: a wake-up lag that stalls the phone for three and a half seconds before waking up from standby. And, the ext2 fix is nowhere near perfect. The ext2 filesystem is far too unstable according to some developers who prefer to execute this fix using ext3 or ext4.
Still, it’s amazing to think that we now have phones that are benchmarking scores twice as high as the Nexus One with Android 2.2 Froyo’s JIT compiler. This phone should fly on Froyo.
Click if you want to learn more about the ext2 hack or the 1.2 GHz overclock kernel.
Click to expand...
Click to collapse
source:briefmobile.com/samsung-captivate-reaches-new-speeds
i thought this was amazing news to be able to boost a phones performance so much and was wondering if this virtual filesystem hack could be implemented on the desire? Or has anyone actually alreaady tried it? I am aware the desire supports ext partitions in hacked roms but i am not aware of any roms that have implemented the ext filesystem in this way
thekeiron said:
i thought this was amazing news to be able to boost a phones performance so much and was wondering if this virtual filesystem hack could be implemented on the desire? Or has anyone actually alreaady tried it? I am aware the desire supports ext partitions in hacked roms but i am not aware of any roms that have implemented the ext filesystem in this way
Click to expand...
Click to collapse
I suspect you will find that this only works on the Galaxy S because of the RFS filesystem. Since the Desire doesn't use RFS, there would be no benefit.
Regards,
Dave
Ah i see that is a bummer! thanks for the reply anyway
To all developers, would this be possible on the tmo g2?
http://forum.xda-developers.com/showthread.php?t=859419
http://forum.xda-developers.com/showthread.php?t=864174
I know the tmo g2 has more security issues so maybe the hack won't work but it would be awesome if some devs would jump on that. Imagine the quad. scores we would get clocked @ 1.8ghz and with this mod.
Front page post:
http://www.xda-developers.com/android/new-hack-for-desire-and-nexus-one-data2ext/
They already have a 1.8 oc lol and have got 3000 quad scores just look for 2 secs you will find it
Sent from my HTC Vision using XDA App
bmaing2 said:
They already have a 1.8 oc lol and have got 3000 quad scores just look for 2 secs you will find it
Sent from my HTC Vision using XDA App
Click to expand...
Click to collapse
I know this. Im saying imagine this mod on top of the 1.8ghz. I mean I did mention 1.8ghz in the first post?
I think this is a great idea..the first time I saw this being done was in the vibrant/galaxy s forums and they used it to get rid of the horrible lag on the vibrant...they got amazing results..I've always asked if this cud be done on other phones but I think there has been a little haterade being passed around the forums about quad scores...hating on our g2s of course : )...and wenever I asked I nvr got any feedback..I believe the best version to refer to is the z4 mod lagfix because it converts a few partitions to ext nd gives the phone an all around amazing performance boost..I hope someone gets on this asap..I'm sure it wud be great on sense roms too
Sent from my HTC Vision using XDA App
I agree. I dont know much about android development but if anyone out there is willing to do this I would be more than glad to try it out.
macfan74318
I originally posted this under development and it got moved here. Devs rarely come in this sub forum to notice this. If anyone knows any of the devs involved in the g2 rooting process ask them to check those links out and see if it is even possible for us.
HTC Vision S-OFF CM6.1 Rc3 Oc'd to 1.5ghz on Pershoots Kernel
Would anyone be brave enough to flash the update.zip in those threads and see if it works??? I'd do it myself if someone can confirm it wouldn't brick if I have a nandroid backup.
HTC Vision S-OFF CM6.1 Rc3 Oc'd to 1.5ghz on Pershoots Kernel
ill tell you why no one cares about this, it doesnt work. you are cheating quadrant to get better results but it has only ONE real world performance boost and that was in the vibrant, captivate and the fascinate. the reason for that was they all used a slow horrid 16gb nandchip so by mounting it as a tmpfs you were able to speed it up maginally.
this phones nand is SLC which has been proven to be faster then MLC (as in the phones stated about). dont believe me? pick up the vibrant and use it right next to the epic 4g it has a onenand (SLC) and does not need a "lagfix". instead we as epic owners got a 16gb micro sdcard and 1gb of onboard..
anyways just to clarify again none of the devs care about doing this because they already knew about it. (search for cyanogen cheats quadrant on google) we all know quadrant is a broken system.
shabbypenguin said:
ill tell you why no one cares about this, it doesnt work. you are cheating quadrant to get better results but it has only ONE real world performance boost and that was in the vibrant, captivate and the fascinate. the reason for that was they all used a slow horrid 16gb nandchip so by mounting it as a tmpfs you were able to speed it up maginally.
this phones nand is SLC which has been proven to be faster then MLC (as in the phones stated about). dont believe me? pick up the vibrant and use it right next to the epic 4g it has a onenand (SLC) and does not need a "lagfix". instead we as epic owners got a 16gb micro sdcard and 1gb of onboard..
anyways just to clarify again none of the devs care about doing this because they already knew about it. (search for cyanogen cheats quadrant on google) we all know quadrant is a broken system.
Click to expand...
Click to collapse
This makes perfect sense, I'm not doubting your words but why are people reporting better performance on their device's if this is just cheating quadrant? They say the write speeds are much quicker which makes the performance of the device much better. I'm not trying to sound ignorant I'm just confused. Sorry =/
I just read a tweet from @cyanogen stating anyone who uses this on cm will get no support from them.
HTC Vision S-OFF CM6.1 Stable Oc'd to 1.5ghz on Pershoots Kernel
there is no question of whether or not you will get faster write speeds as you are mounting a "fake" file system. the thing is how often do you really write to your file system? 10-20 times per couple of hours? while quadrant runs tests to see big file transfers and lots of little files, the average user does not. i would say (at least for myself) that 90% of teh phones usage is spent on reading from the file system, not writing to.
read speeds are already fast (well for a mobile device at least ) the only time that you write to your memory is installing apps and changing settings. settings i dont notice ANY lag on that, as for installing apps i would guess at best a 3-6% speedup as you are still writing to physical memory. perhaps the biggest reason why i wouldnt use this is because in order for you to use this you have to have the file system mounted somewhere.. if its mounted on board then your still reading/writing to the same chip. if your mounting it on the sd card then not only do you lose speed overall (unless its class 6 or higher) but now you lose sd card storage.
shabbypenguin said:
there is no question of whether or not you will get faster write speeds as you are mounting a "fake" file system. the thing is how often do you really write to your file system? 10-20 times per couple of hours? while quadrant runs tests to see big file transfers and lots of little files, the average user does not. i would say (at least for myself) that 90% of teh phones usage is spent on reading from the file system, not writing to.
read speeds are already fast (well for a mobile device at least ) the only time that you write to your memory is installing apps and changing settings. settings i dont notice ANY lag on that, as for installing apps i would guess at best a 3-6% speedup as you are still writing to physical memory. perhaps the biggest reason why i wouldnt use this is because in order for you to use this you have to have the file system mounted somewhere.. if its mounted on board then your still reading/writing to the same chip. if your mounting it on the sd card then not only do you lose speed overall (unless its class 6 or higher) but now you lose sd card storage.
Click to expand...
Click to collapse
so then i have a couple questions..if its useless why are they doing it on the nexus "thee development phone" and if its only wen u install apps or change settings..how come it also fixed homescreen lag?
i dont see how lockscreen lag would have improved, but w/e..
Yeah if you read thru the threads people are mentioning better performance almost all around. It is odd tho especially after reading your explanation.
HTC Vision S-OFF CM6.1 Stable Oc'd to 1.5ghz on Pershoots Kernel
>.> my apologies i just read the threads, i had just figured this was the same lagfix as the vibrant etc. no in theory this would indeed work ok.. assuming your sd card is faster then your onboard storage. my class 4 16gb is clearly not
shabbypenguin said:
>.> my apologies i just read the threads, i had just figured this was the same lagfix as the vibrant etc. no in theory this would indeed work ok.. assuming your sd card is faster then your onboard storage. my class 4 16gb is clearly not
Click to expand...
Click to collapse
So your saying we would need a class 8 or class 10 to make this work? No need to appologize. You were just trying to clear things up for us. Surely taught me about the lagfix.
So I'm no dev. But I just got laid off of work, what are the basics needed to work on something like this? Or better yet porting it over to the htc vision?
HTC Vision S-OFF CM6.1 Stable Oc'd to 1.5ghz on Pershoots Kernel
not work, but to be effective i would imagine that yea higher then 6 would be useful.
but i would read this article
http://www.androidcentral.com/bell-samsung-galaxy-s-phones-dying-bad-hardware-or-bad-hacks
shabbypenguin said:
not work, but to be effective i would imagine that yea higher then 6 would be useful.
but i would read this article
http://www.androidcentral.com/bell-samsung-galaxy-s-phones-dying-bad-hardware-or-bad-hacks
Click to expand...
Click to collapse
This has to do with the galaxy S' lag fix. It states that they have the not so best type of hardware in their phone which is one of the reasons their media card reader is failing. The only way to be sure this actually will mess our phones up is by going for it. I like to mess with anything that makes my device perform better. I honestly could care less about quadrant scores.
HTC Vision S-OFF CM6.1 Stable Oc'd to 1.5ghz on Pershoots Kernel
they also mention that micro sd's dont like to be partitioned every which way.. (of course if this is successful then its a one time thing)
shabbypenguin said:
(search for cyanogen cheats quadrant on google)
Click to expand...
Click to collapse
When that is searched the first result it this thread Just sayin
(Oh and I know it probably wont boost real world performance but it has doubled there hero's quadrant score
http://forum.xda-developers.com/showthread.php?t=991276
Found that a couple days ago and was wondering if anyone has tried it or if most developers use something similar as a base.
I've tried it with Jermaine151's Minimalist ROM...and honestly I really don't notice any differences with how things run. My cousin, who has the OG Droid, swears by it.
localceleb said:
http://forum.xda-developers.com/showthread.php?t=991276
Found that a couple days ago and was wondering if anyone has tried it or if most developers use something similar as a base.
Click to expand...
Click to collapse
Kernel devs use a released kernel as a base, not a script. A kernel dev worth his salt has already made memory tweaks according to how he feels the system should run. I'm not sure what that script is supposed to fix or how lag and slow draw times are related to memory. Motorola devices are seriously challenged in that department, but HTC's are some of the best out there. I'm not sure where he came up with the idea that no-op IO queuing was as good as deadline. That's couldn't be more wrong. That also makes me question his other tweaks. Basically, if you're running a custom kernel, especially something like the seriously modified ziggy or AOSP kernels, I'd avoid this.
RMarkwald said:
I've tried it with Jermaine151's Minimalist ROM...and honestly I really don't notice any differences with how things run. My cousin, who has the OG Droid, swears by it.
Click to expand...
Click to collapse
Did you get the feeling it was really aimed at Motorola devices, too?
loonatik78 said:
Did you get the feeling it was really aimed at Motorola devices, too?
Click to expand...
Click to collapse
Yeah I did. I kinda figured that running a custom ROM/kernel combo would be ideal instead of running that script, just because the devs have tweaked/maximized their performance already.
I don't know if that's the case with a Moto device, as I have the Xoom but never owned the phone. My cousin swears by it on his OG Droid, and pointed it out to me.
Like you said, I think with HTC devices you won't really notice much, if any differences. I haven't personally.
RMarkwald said:
Yeah I did. I kinda figured that running a custom ROM/kernel combo would be ideal instead of running that script, just because the devs have tweaked/maximized their performance already.
I don't know if that's the case with a Moto device, as I have the Xoom but never owned the phone. My cousin swears by it on his OG Droid, and pointed it out to me.
Like you said, I think with HTC devices you won't really notice much, if any differences. I haven't personally.
Click to expand...
Click to collapse
Well, like I said, I'm suspect simply because he thinks no-op is a good IO scheduler. It kinda tells me he doesn't know his ass from a hole in the ground. No-op assumes mechanical storage mediums. Deadline is MUCH better for solid state storage, and all the rest of the schedulers are improvements that may or may not be better, depending on how you use your device.
I know deadline is better...but not all phones have deadline available.
I'm no guru on the topic and I go by what I read and read threads about the topic.
I don't take credit for the non-supercharger tweaks as they aren't mine and include links that I used as resources.
Yes I do say noop or deadline would be preferred over other common options on most devices. But the main thing is that both would be faster than what most people have configured - cfq.
btw, this thread seemed convincing that noop is performs very well on android
http://forum.xda-developers.com/showthread.php?t=948001
So forgive me for not consulting you first.
Oh, also...
NOOP scheduler is best used with solid state devices such as flash memory or in general with devices that do not depend on mechanical movement to access data (meaning typical "hard disk" drive technology consisting of seek time primarily, plus rotational latency). Such non-mechanical devices do not require re-ordering of multiple I/O requests, a technique that groups together I/O requests that are physically close together on the disk, thereby reducing average seek time and the variability of I/O service time.[2]
Click to expand...
Click to collapse
http://en.wikipedia.org/wiki/Noop_scheduler
But then again, you probably would have given me wrong information.
PS. So it seems that you're not all the bright either
zeppelinrox said:
I know deadline is better...but not all phones have deadline available.
I'm no guru on the topic and I go by what I read and read threads about the topic.
I don't take credit for the non-supercharger tweaks as they aren't mine and include links that I used as resources.
Yes I do say noop or deadline would be preferred over other common options on most devices. But the main thing is that both would be faster than what most people have configured - cfq.
btw, this thread seemed convincing that noop is performs very well on android
http://forum.xda-developers.com/showthread.php?t=948001
So forgive me for not consulting you first.
Oh, also...
http://en.wikipedia.org/wiki/Noop_scheduler
But then again, you probably would have given me wrong information.
PS. So it seems that you're not all the bright either
Click to expand...
Click to collapse
Yes. I'm aware of all that. The shortcoming of no-op is that it doesn't take into account demands of data. Some data should be fetched before other data, thus requiring a re-ordering of requests. It is best used on solid-state devices, but not THE best choice for them, necessarily. One might assume no-op to be roughly on par with deadline if some course assumptions about solid-state are made. No-op would be ideal on the SCSI5 array I built because a storage subsystem controller is re-ordering the data and caching it to memory. The latency times on that memory are exceeding low, as are write operations. In fact, the controller would send write-confirm commands back to the system even before data was actually written to disk to allow for more I/O operations. NAND solid-state is a different creature though. Read latency is certainly fast, however write latency is much, much slower in comparison. Because of this, simply throwing read and write commands at the storage subsystem wastes a lot of time since reads must wait on lengthy writes. Deadline holds significant advantage over no-op because it will suspend writes operations to ensure read request deadlines are met. In short, it mitigates some of the shortfall that comes with the NANDs lengthy write times. That's why I say it's significantly better.
I see.
That's very informative indeed.
Perhaps I can determine of a user has deadline available and if so, use that and if not, use noop
zeppelinrox said:
I see.
That's very informative indeed.
Perhaps I can determine of a user has deadline available and if so, use that and if not, use noop
Click to expand...
Click to collapse
I've never professed to be a software guy by any stretch of the imagination. I will never be able to do what you and many, many others do with software, code, Linux, scripting... and of that. I just don't understand that stuff. I'm very much the hardware geek though. Column address strobes? Sense amps? I get that kind of talk. Looking at a script? It might as well be in Sumerian.
zeppelinrox said:
I know deadline is better...but not all phones have deadline available.
I'm no guru on the topic and I go by what I read and read threads about the topic.
I don't take credit for the non-supercharger tweaks as they aren't mine and include links that I used as resources.
Yes I do say noop or deadline would be preferred over other common options on most devices. But the main thing is that both would be faster than what most people have configured - cfq.
btw, this thread seemed convincing that noop is performs very well on android
http://forum.xda-developers.com/showthread.php?t=948001
So forgive me for not consulting you first.
Oh, also...
http://en.wikipedia.org/wiki/Noop_scheduler
But then again, you probably would have given me wrong information.
PS. So it seems that you're not all the bright either
Click to expand...
Click to collapse
I forgot... I also wanted to explain that XDA thread a little.
It looks like he's basing his times on sequential writes, reads, then erases. Were that similar to real world use, his results would be valid, but seldom does anything work like that. Without knowing the specific IC of the flash drive in use, certain features of it can only be guessed at. Unless it's a virgin device or written to 0's, chances are writes are also going to come in conjunction with erases, which are a completely different process, and just as lengthy as writes. Because of how NAND works, larger erases and writes can be accomplished much faster by the address block rather than on a file by file basis. This is because NAND can only address blocks at a time. It has no random access capability for pages or bytes, either reading or writing. In short, his test demonstrates an ideal circumstance, one that is RARELY the circumstance of the real world.
I ran his V6 Supercharger script, Kick Ass Kernel Tweaks, and the 3G turbocharger tweaks in build.prop....
noticed NO difference whatsoever...
Actually, that isn't true. The one thing that seemed to work was the part about making the home launcher "hard to kill", that actually seemed to work. I was having issues with Sense restarting itself, and this alleviated that issue. I noticed that even if I tried to manually stop sense, I couldn't kill it. Two weeks later I removed all trace of the V6 scripts and haven't had any issues since, no idea why, although now I can manually kill the Sense process and have it restart again.
Anyways... no, there was no performance increase whatsoever.
bast525 said:
I ran his V6 Supercharger script, Kick Ass Kernel Tweaks, and the 3G turbocharger tweaks in build.prop....
noticed NO difference whatsoever...
Actually, that isn't true. The one thing that seemed to work was the part about making the home launcher "hard to kill", that actually seemed to work. I was having issues with Sense restarting itself, and this alleviated that issue. I noticed that even if I tried to manually stop sense, I couldn't kill it. Two weeks later I removed all trace of the V6 scripts and haven't had any issues since, no idea why, although now I can manually kill the Sense process and have it restart again.
Anyways... no, there was no performance increase whatsoever.
Click to expand...
Click to collapse
I was curious as to the Sense launcher restarting itself, and if this would fix/have an impact on that issue. Thanks for the info!
anyone that gave loonatik a hard time on this site seriously needs to reconsider, this guy knows his stuff.
loonatik78 said:
I forgot... I also wanted to explain that XDA thread a little.
It looks like he's basing his times on sequential writes, reads, then erases. Were that similar to real world use, his results would be valid, but seldom does anything work like that. Without knowing the specific IC of the flash drive in use, certain features of it can only be guessed at. Unless it's a virgin device or written to 0's, chances are writes are also going to come in conjunction with erases, which are a completely different process, and just as lengthy as writes. Because of how NAND works, larger erases and writes can be accomplished much faster by the address block rather than on a file by file basis. This is because NAND can only address blocks at a time. It has no random access capability for pages or bytes, either reading or writing. In short, his test demonstrates an ideal circumstance, one that is RARELY the circumstance of the real world.
Click to expand...
Click to collapse
I did think that the noop result was too good in relation to the other results.
I would not think that it was that much faster (since deadline is better) so I was somewhat surprised.
Thanks for elaborating
On the Sensation, the Supercharger script gave me no speed increase. It did fix my launcher redraws though. The only thing this script helped me with is multitasking, switching between apps constantly was smoother, and more often they didn't get killed by Android's task manager.
On the Nexus S though, it did make a good amount of difference in the operation of the phone.
I think, on the faster phones, like the SGS2 and the Sensation, it only helps with multitasking..
Well I initially came up with it because of the launcher redraw issue... everything else was gravy... well... a whole lotta gravy...
I don't think SuperSmoother sounds as cool so I'll stick with SuperCharger anyway lol
I've seen the Pixel 3 and later models have gained full F2FS filesystem support since F2FS implemented native support for file-based encryption.
Is this possible with our device, or did I miss something? Is anyone else looking for this to be implemented?
All flash devices seem to benefit long term from F2FS. It also gets repetitive having to run fstrim in terminal manually on a weekly basis for EXT4. A part of me says I'm nitpicking cause everything functions perfectly on this device. But I see even greater potential here with F2FS.
I get that some people get excited about new filesystems and see benchmarks and buy into it totally, but
i tested f2fs on my previous device, Galaxy Note 4 (and before that S4), and i was never convinced it did
anything look good in synthetic benchmarks. In every day use i couldnt have told you the difference.
But then one difference i can tell you, is that once you've had your first corrupt fs using f2fs, you'll quickly
retreat to the safety of ext4...ive never had a corrupt fs under ext4....
So i guess youre now going to say, "but newer devices use f2fs, so it cant be that unsafe" to which im going
to answer "yes, but theyve since tuned down or disabled some of the flags/features that people used to use to get
inflated synthetic benchmarks, so its no faster in real world than ext4"
And like i said, i could never tell the difference in real world usage between the two....
Also im pretty sure that on stock RM you dont need to manually run fstrim, i assume that would run on schedule
or during idle
Plus TWRP for the Pixel 2/2XL doesnt support formatting partitions in f2fs, so theres that
73sydney said:
I get that some people get excited about new filesystems and see benchmarks and buy into it totally, but
i tested f2fs on my previous device, Galaxy Note 4 (and before that S4), and i was never convinced it did
anything look good in synthetic benchmarks. In every day use i couldnt have told you the difference.
But then one difference i can tell you, is that once you've had your first corrupt fs using f2fs, you'll quickly
retreat to the safety of ext4...ive never had a corrupt fs under ext4....
So i guess youre now going to say, "but newer devices use f2fs, so it cant be that unsafe" to which im going
to answer "yes, but theyve since tuned down or disabled some of the flags/features that people used to use to get
inflated synthetic benchmarks, so its no faster in real world than ext4"
And like i said, i could never tell the difference in real world usage between the two....
Also im pretty sure that on stock RM you dont need to manually run fstrim, i assume that would run on schedule
or during idle
Plus TWRP for the Pixel 2/2XL doesnt support formatting partitions in f2fs, so theres that
Click to expand...
Click to collapse
Totally agreed on this tried it on nexus 7 2012 and Galaxy Nexus back in the day never was convinced and the downsides are way to much. Ext4 is overall more mature and the available toolkits are much better. If anyone wants to read about it goto the arch wiki, they had a comprehensive write-up on the different file systems.
EXT4 is indeed mature but it was also designed to run on spinning rust. Therefore it will always be a patchwork to keep it running efficiently on flash storage (scripts to run routine fstrim's)
@ReVo_007 you say look up the wiki on each file system; well if anyone were to do that they would realize f2fs is the optimal filesystem for flash storage since it is designed specifically for flash storage, including maximizing the life by distributing writes evenly across all data blocks and increasing read-write performance by building a cache of all data blocks, as well retaining the original read-write performance.
I hope to see f2fs on our device, the performance boost alone would be worth it, especially with apps that rely heavily on cache like Chromium.
I've tested f2fs on many devices, and actually the faster your processor the more it shines because the cache can run more efficiently, especially with native compression enabled. My desktop PC on Fedora 34 runs great, my cheap modded chromebook runs as fast as a high end one ever since I formatted all Fedora partitions as f2fs, a fun project of mine.
ThunderThighs said:
EXT4 is indeed mature but it was also designed to run on spinning rust. Therefore it will always be a patchwork to keep it running efficiently on flash storage (scripts to run routine fstrim's)
@ReVo_007 you say look up the wiki on each file system; well if anyone were to do that they would realize f2fs is the optimal filesystem for flash storage since it is designed specifically for flash storage, including maximizing the life by distributing writes evenly across all data blocks and increasing read-write performance by building a cache of all data blocks, as well retaining the original read-write performance.
I hope to see f2fs on our device, the performance boost alone would be worth it, especially with apps that rely heavily on cache like Chromium.
I've tested f2fs on many devices, and actually the faster your processor the more it shines because the cache can run more efficiently, especially with native compression enabled. My desktop PC on Fedora 34 runs great, my cheap modded chromebook runs as fast as a high end one ever since I formatted all Fedora partitions as f2fs, a fun project of mine.
Click to expand...
Click to collapse
There is no "performance boost" under real world conditions, in test on previous devices where f2fs WAS available the was only a difference in synthetic benchmarks, which is what everyone gets a boner about...the difference isnt enough for me to give up the stability of ext4
fstrims are handled by the OS in modern Android versions, no scripts needed...
on this device if youre not gaming, you'll do more by disabling swap than changing the fs to f2fs...
73sydney said:
There is no "performance boost" under real world conditions, in test on previous devices where f2fs WAS available the was only a difference in synthetic benchmarks, which is what everyone gets a boner about...the difference isnt enough for me to give up the stability of ext4
fstrims are handled by the OS in modern Android versions, no scripts needed...
on this device if youre not gaming, you'll do more by disabling swap than changing the fs to f2fs...
Click to expand...
Click to collapse
Just because you didn't notice anything and experienced instability on a 4+ year old device doesn't mean the entire filesystem is garbage.
I experience quite the opposite on my desktop PC and OnePlus One, infact not only do apps open faster, the system boots faster, large file transfers are 25% faster, and fstrim isn't ever needed.
BTW, android does have a scheduled fstrim but I've found its only ran on a monthly basis and this is unacceptable for how heavily I use my device.
You're also forgetting about the main draw to F2FS is the proven increase in service life of flash storage it's deployed on.
I never said the "filesystem is garbage", please dont assign words to me i never said, typical fanboy move, and a tired one at that
also, top tip, the entire slew of devs is not just waiting here for you to tell them whats not suitable for your usage and ready to jump
btw modern android does fstrim daily at idle, usually at night when youre all tucked up dreaming about how f2fs is the answer to every perceived issue
i have an S2 that still works, only ever had EXT fs on it...now a decade old, with far inferior flash memory on it, how much more life do you expect to have?
ive yet to meet anyone who has said to me "i just upgraded my phone because the flash finally died on it", theyre usually aspirational techno-numptie sheeple who think they need a new phone every 6 months, because giant skivvy told them they did. Apple really IS the root of all evil in modern tech
sorry but i have to debunk bunkum where i see it
If youre detemined to run fstrim more than the scheduled amount, feel free to give the following magisk module ive cooked just for you (and anyone else reading this) a crack
Only active file is fstrim.sh which will be written to /data/adb/service.d/fstrim.sh so its executed at boot
It merely checks the date of the /data/system/last-fstrim and if its been more than 24 hours, it will start an fstrim on /data, /cache/ and /system
Code:
removed due to ungratefulness
Please note: As this only executes after boot complete, it may take some time to start depending on system processes and other service scripts
And then theres always this (ad free) if you want even more control, or just want an app to do what my module does on a daily basis
Trimmer (fstrim) - Apps on Google Play
Trim your device NAND chip manually and fix lags.
play.google.com
You might also want to read this post:
mFSTRIM: A REAL, FOSS fstrim utility for Android, no root necessary
Hey XDA! I actually just posted about another app called Buoy, but over my spring break I went ham and made four apps and I wanted to show off two of them to get some feedback. So here's mFSTRIM! What is fstrim? So you know how hard drives get...
forum.xda-developers.com
MOD EDIT: Quote removed since post removed.
1) Not a sketchy 3rd party script, and i posted the content of it for safety&clarity. If thats sketchy you will probably hate most modules and zip files on XDA
2) If you can do it in a terminal why are you even raising an issue with fstrim? Feel free to enter the commands manually every time you need them, just to avoid taking any assistance offered....
3) I dont have a vendetta against anything, im merely giving an opinion, based on known facts - that you dont like facts is not my problem.
4) Ive given you more than a few links to apps etc to get you actual improvements without waiting for f2fs which will likely never come, because as already highlighted its not as simple as just adding ti to a kernel, youre welcome
MOD EDIT: A sentence repeating a portion of the deleted post and answering it deleted. Go and look elsewhere for help is my suggestion, you dont appear to want to take any advice given here....
I literally dont care what fs you use, that you even think that is troubling, you made that an issue, not me....
Accept the assistance offered or not, no one cares, but insulting me and the entire forum is unlikely to win you any further help
ThunderThighs said:
I've seen the Pixel 3 and later models have gained full F2FS filesystem support since F2FS implemented native support for file-based encryption.
Is this possible with our device, or did I miss something? Is anyone else looking for this to be implemented?
All flash devices seem to benefit long term from F2FS. It also gets repetitive having to run fstrim in terminal manually on a weekly basis for EXT4. A part of me says I'm nitpicking cause everything functions perfectly on this device. But I see even greater potential here with F2FS.
Click to expand...
Click to collapse
F2FS is designed with flash storage in mind. However, EXT4 is used because it has been proven to be more robust. In other words, the chances of corrupting your data are far smaller on EXT4 than on F2FS. Which is why, unless Google changed it for the Pixel 3 and onward, they use EXT4 for their partitions.
Is it possible on the Pixel 2 XL? Anything is possible, but if you want it, you're going to have to do the work yourself. The developers on the forum haven't implemented it in their ROMs, and they likely have a very good reason behind it. Ask them, and I'm sure they'll tell you.
Now, you claim F2FS is better than EXT4. Do you have empirical data to back that up, or is it simply your opinion? If the former, show your data so everyone can make an informed decision. If the latter, that's something you are entitled to, but your right to express that opinion stops when it starts trampling on the opinions of others.
MOD EDIT: Unnecessary comments removed.