What are the chances of being able to ditch all the concerns that go along with Ext2, Ext3, and Ext4 hacks to improve read-write on the Captivate by going with YAFFS or YAFFS2?
http://en.wikipedia.org/wiki/YAFFS
YAFFS is an optimized filesystem for use with NAND flash memory, would it provide the stability and speed we're looking for?
I know this idea has been discussed lightly before in the various "lag fix" threads, but I was wondering if users with knowledge could enlighten the rest of us on the YAFFS filesystem.
I may be way wrong here, but judging by a few commands I've seen regarding busybox install issues, is it possible the stock kernel supports this already?? In which case could we modify the current lag fixes to use it instead?
Since this is related and I already posted this in Nuka's thread:
http://forum.xda-developers.com/showthread.php?t=750663
Those wacky gents over in the I9000 section have managed to get YAFFS2 compatibility into the kernel. This is something we should probably look into once we've figured out the wake-lag issue (maybe sooner )
In other news, assuming we can get YAFFS2 plugged into our kernel, how feasible (albiet probably complicated) would it be to actually REPLACE RFS and then load the OS on top of YAFFS2? There's just something about cascading file systems written on top of each other that sounds like trouble to me.
Zilch25 said:
Since this is related and I already posted this in Nuka's thread:
http://forum.xda-developers.com/showthread.php?t=750663
Those wacky gents over in the I9000 section have managed to get YAFFS2 compatibility into the kernel. This is something we should probably look into once we've figured out the wake-lag issue (maybe sooner )
Click to expand...
Click to collapse
Nice find!
I agree, the wake-up-lag issue is bothersome. Looking forward to mimocan possibly helping us out with his solution that he offered the Samset people.
kennethpenn said:
What are the chances of being able to ditch all the concerns that go along with Ext2, Ext3, and Ext4 hacks to improve read-write on the Captivate by going with YAFFS or YAFFS2?
http://en.wikipedia.org/wiki/YAFFS
YAFFS is an optimized filesystem for use with NAND flash memory, would it provide the stability and speed we're looking for?
I know this idea has been discussed lightly before in the various "lag fix" threads, but I was wondering if users with knowledge could enlighten the rest of us on the YAFFS filesystem.
Click to expand...
Click to collapse
Using a FS designed for Flash media will help with some of the fixes but not all. For example the mimocan fix it should help, as it will reduce overhead and increase the longevity of the Flash. Also since the mimocan fix is on the external card, it is properly un-mounted at shut down so this helps stop corruption.
Conversly it won't really do anything for the ext2 fix because that is a virtual disk sitting on top of another FS, which is not un-mounted at shutdown.
Potentially a custom ROM could replace the FS on the internal flash, but Samsung must have did what they did for a reason. It is hard to tell if they did what they did because they were lazy / didn't know any better, or they knew something we don't.
Bjd223 said:
Potentially a custom ROM could replace the FS on the internal flash, but Samsung must have did what they did for a reason. It is hard to tell if they did what they did because they were lazy / didn't know any better, or they knew something we don't.
Click to expand...
Click to collapse
Samsung use rfs because for some misguided and twisted reason some manager there thinks it is good and proprietary so they have a leg up on the competition. They go on about how quick rfs mounts as a benefit (yaffs and other flash files systems are slow to mount).
RFS isn't exactly terrible in the right places - the /dbdata symlink hack works because RFS-on-NAND is faster than RFS-on-SD, even though raw reads on the internal SD are faster than on the OneNAND partitions. I suspect it simply interacts poorly with devices that already do their own remapping and wear-leveling, or perhaps that the performance hit is a result of using much larger blocks on /data. I wonder what would happen if one just formatted /data with smaller blocks than 16KiB?
kennethpenn said:
YAFFS is an optimized filesystem for use with NAND flash memory
Click to expand...
Click to collapse
That already explains it all. I do not think it can be used on SD. This is copy-paste from UBIFS, but I believe it is the same for YAFFS:
This is why UBIFS does not work on MMC cards and the like - they look like block devices to the outside world because they implement FTL (Flash Translation Layer) support in hardware, which simply speaking emulates a block device on top of the built-in raw flash.
Click to expand...
Click to collapse
For the ext2 hack with loop device (file formated as ext2) I have no idea if it is any better.
Why do I feel like i'm the only one without the wake up lag issue? .
tbae2 said:
Why do I feel like i'm the only one without the wake up lag issue? .
Click to expand...
Click to collapse
I bet u r on stock kernel
Sent from my SAMSUNG-SGH-I897 using XDA App
Doesn't the Captivate already use yaffs2? Try running "mount" in a terminal emulator or in adb shell.
junknuts said:
Doesn't the Captivate already use yaffs2? Try running "mount" in a terminal emulator or in adb shell.
Click to expand...
Click to collapse
no, it uses rfs for everything...
yaffs2 is not really any better than rfs, both file systems, however, are not intended for use on SD memory. In other words you would be exerting great effort to get yaffs2 as your file system for the NAND part of your phone, and get little to no improvement. As for the mimocam fixes and the like that use your SD card or Internal Memory (Internal SD Card essentially), ext2, 3, or 4 would still be better options than yaffs2 or rfs as they are intended for true NAND Flash memory not block based SD memory.
tbae2 said:
Why do I feel like i'm the only one without the wake up lag issue? .
Click to expand...
Click to collapse
Ok, silly question...what is "wake up lag"? Either thats too technical of a term, or too vague, I dont really get it.
derek4484 said:
Ok, silly question...what is "wake up lag"? Either thats too technical of a term, or too vague, I dont really get it.
Click to expand...
Click to collapse
When you don't use your phone for a while, the phone goes into a "sleep" mode where the screen is totally black and does not respond to any touch. To "wake up" the phone, you press the power button, after which you can see the phone locked screen, and the screen responds to touch again. On a normal Captivate with the precompiled kernel installed by Samsung, or on a Captivate where you have flashed the same precompiled kerenel via Odin, the delay between pressing the power button, and seeing the phone locked sceen is usually less than a second or so. On phones where a kernel compiled from the Samsung released source code (either with or without any modifications) is flashed on, there is a much longer delay between the power button press, and the phone waking up to show the phone locked screen. This is what we mean by wake up lag. We still don't know what causes the rebuilt kernels to lag on wake up.
*Moved question to General*
Flash memory: NAND vs SD?
Hello,
Mr Taco above made a distinction that I can't figure out. He suggests that YAFFS is for "NAND" memory and not "block based SD." Here is my confusion.
From what I have read, it appears as though typical flash multimedia drives, such as MMC and other SD cards, are all created from NAND chips (as opposed to the less-memory-dense NOR chips). So I do not understand the distinction between "NAND" and "SD."
Also, he mentions "block based" devices. But as far as I can tell, "block level" has to do with the *interface* to storage and not the nature of the storage itself. For example, one could map a bunch of random access memory and present it as a block device (say, so it could be treated as a disk with a filesystem). Similarly, mmap and other techniques use disk storage with a memory-like interface (as opposed to a block interface).
So here are some questions I have that might help me figure this out:
1. Presumably the Captivate has some true RAM, that is, non-NAND chips that give truly random access memory that is not persistent upon shutdown.
2. That RAM has a normal (non-MTD) interface (512MB?).
3. Besides this RAM, the Captivate has an internal NAND-based flash drive (2gb).
4. It also has another internal NAND-based flash drive (16GB).
5. It has an external slot for a micro sd card, a NAND-based flash device accepting up to 32GB.
If these are all true, I have questions.
A. Is mimocam's (sp?) solution to use actual RAM, synced to flash, to load certain partitions?
B. Or is his solution implemented on the internal 2GB flash?
C. Certainly, other solutions have used external and internal flash (the ext2 solution, for example).
D. So, isn't it still true that any solution that would rely on the 2GB, internal 16GB or external NAND-flash would profit from using YAFFS?
Thank you in advance,
-0
zeroaltitude said:
Mr Taco above made a distinction that I can't figure out. He suggests that YAFFS is for "NAND" memory and not "block based SD." Here is my confusion.
From what I have read, it appears as though typical flash multimedia drives, such as MMC and other SD cards, are all created from NAND chips (as opposed to the less-memory-dense NOR chips). So I do not understand the distinction between "NAND" and "SD."
Click to expand...
Click to collapse
I'll repeat once again, it is from UBIFS page, but afaik it is the same for yaffs and others:
One thing people have to understand when dealing with UBIFS is that UBIFS is very different to any traditional file system - it does not work on top of block devices (like hard drives, MMC/SD cards, USB flash drives, SSDs, etc). UBIFS was designed to work on top of raw flash, which has nothing to do with block devices. This is why UBIFS does not work on MMC cards and the like - they look like block devices to the outside world because they implement FTL (Flash Translation Layer) support in hardware, which simply speaking emulates a block device on top of the built-in raw flash.
Click to expand...
Click to collapse
"One thing people have to understand when dealing with UBIFS is that UBIFS is very different to any traditional file system - it does not work on top of block devices (like hard drives, MMC/SD cards, USB flash drives, SSDs, etc). UBIFS was designed to work on top of raw flash, which has nothing to do with block devices. This is why UBIFS does not work on MMC cards and the like - they look like block devices to the outside world because they implement FTL (Flash Translation Layer) support in hardware, which simply speaking emulates a block device on top of the built-in raw flash."
Although I do appreciate the attempt to answer my questions, this reply is very puzzling.
My question was why did Mr Taco make a *distinction* between SD and NAND as far as flash memory goes. The reply, quoted above, *lumps SD and NAND devices together*. Furthermore, the primary topic of the quotation is yet another filesystem, UBIFS, that is not even under discussion (at least, not in my post it wasn't).
So, I'm happy to read up on UBIFS, however, I don't see how that can possibly answer the specific questions I have. I hope someone with some familiarity with device drivers or filesystem internals will drop by this thread. Otherwise, it's back to the research .
-0
NAND flash is typically configured so that for each block of stored data, there is a sub-block for supplementary data. This is used for wear-levelling, etc. "Raw" NAND devices such as kernel mtd devices expose this as well as the data portion of each block, and filesystems like yaffs2 and ubifs incorporate wear-levelling into the filesystem design, and rely on having direct access to raw flash.
SD cards contain a controller that does its own wear-levelling, and expose only the data segment of each block. Yaffs2 and ubifs will simply not work on such a device, nor are they really appropriate choices for it. A block-oriented filesystem is needed here, and because we can't guarantee graceful shutdowns, it needs to have some sort of data integrity scheme. Ext3/4 are journalled, Samsung's RFS is FAT with copy-on-write added, and the other possibilities here are nilfs2 and btrfs - but there are no backports of reasonable recent btrfs versions for the kernel Samsung has provided to us.
Unhelpful said:
nilfs2 and btrfs - but there are no backports of reasonable recent btrfs versions for the kernel Samsung has provided to us.
Click to expand...
Click to collapse
Thanks. I'm a bit boring to explain the basic things ppl can google first.
About fs. Do we need metadata or block level journaling?
We can consider ReiserFS or JFS? btrfs sounds nice tho.
Hy all!
I found a very interesting post over at samdroid.net
My question is its possible to port this mod for our hero?
Link:
http://forum.samdroid.net/f55/i-o-performance-boost-migrate-your-spica-ext2-2218/
Info:
What does it do?
Reformatting /data as ext4 (as it needs journaling for safety), and /system as ext2(as it is mounted ro all the time).
Thx for the answer.
Regards
Wenner
It gives performance boost on Samsung phones because Samsung has it's own filesystem which slows down whole system. Reformatting it to ext gives boost because ext is faster. HTC Android devices has ext partitions as default so it isn't needed.
Wrong, on all counts.
The storage partitions on the HTC Hero and other devices is nand memory, not a block device. ext filesystem is designed for block devices. The filesystems on /data /system /cache etc are all yaffs2, a filesystem designed specifically for Memory Technology Devices like the NAND in our phones.
Furthermore, even if you could format /data, /system etc as a filesystem other than yaffs2 you'd have to do it from outside the ROM, either via recovery or hboot somehow. A journalling filesystem is destructive to flash memory because flash memory has a finite number of writes before it fails. You'd also have to have a custom kernel if the default kernel doesn't support the filesystem you want to switch to.
If you use old style apps2sd and therefore have a partition for it on your sdcard, they're set up to emulate block devices and you should use ext2 for the reasons pointed out earlier. sdcards are still flash memory at heart and thus journalling is destructive.
Thanks for explanation, but i have question - why we don't use yaffs2 for app2sd (which is designed for flash memory)?
And which is faster - yaffs2 or ext2? On Samsung devices reformatting whole system to ext2 gives performance boost (in comparision to RFS).
Hey all, I'm having a bit of a dilemma and hoping some of you can help me
So - with the introduction of NAND, we are finally able to run Android similar to a native device. Great!
I've dabbled with a large number of ROM's now and settled(ish) on a basic Desire ROM which I have to say, runs absolutely perfectly.
However, I'm missing some of the features from the DesireHD SD card days and I see there are various builds. I tried a squashedfs build and found that it was far more laggy than the unsquashed Desire build I use now.
I've just noticed that there are number of newer builds using an EXT partition on the SD card to store the apps while the ROM itself sits in the NAND.
But is it worth it is my question? Running all the apps off an SD card, surely is akin to just running the whole system from SD? Also, what's the difference between EXT3 and EXT4? I've seen a ROM which advise to use EXT3 while the other suggests 4.
Finally, if the apps run from a partition, does that mean USB Mass Storage connection is out of the question?
Phew. Thanks
NAND is suppose to have a faster read, than write when compared to SD.
NAND and SD has about 100,000 P/E cycles. SD is cheaper to replace than phone, but by the time you get to that many write cycles, your phone is an antique.
You can still use SD card when in USB Mass Storage mode. You will only see the FAT32 partition in Windows. Unless you use a 3rd party program for usb mass storage mode.
ext4
ext3
Comparison of all file systems
There isn't that much difference in ext4 and ext3, especially on a phone. ext2 is probably faster than ext3, but it doesn't have journaling, so, the data is more likely to corrupt when device is not properly turned off.
LiFE1688 said:
There isn't that much difference in ext4 and ext3, especially on a phone. ext2 is probably faster than ext3, but it doesn't have journaling, so, the data is more likely to corrupt when device is not properly turned off.
Click to expand...
Click to collapse
So in fact, if I use a DesireHD CWK Rom with the Apps stuck in EXT4 lets say, it won't be a massively notable difference to say just a Desire CWK Rom on NAND because the OS is still on NAND and it's just the apps that aren't. Furthermore, once they are in the RAM, it makes little difference anyway, right?
There is a difference in ext4 and ext3. Not all kernels support ext4 is probably the biggest. ext4 doesn't cause files fragmentation as much as ext3. Unfortunately, none of us used ext3/4 partitions in SD card long enough to notice the speed lost when files are fragmented in the ext3/4 partition.
So if you are going to use Desire build, check to see if the kernel supports ext4 in the first place. So far, I have seen MDJ's 10 Kernels supporting ext4, other than that, I don't remember seeing another.
Great, I'll see what happens! Thanks
Introdution:
After all the rumers about ext2 rhat it 's not faster than ext4 and its no secured and blah blah, it's all lies and a kind of war against DamianGto..
However I tested by my self all those rumors and its found to be a big lie! EXT2 IS MUCH MORE FASTER THAN EXT4 AND THE SECURITY IS ON THE SAME LEVEL .
GUIDE:
Flash your favorite GB rom (for this guide it's 2.3.5+) (if you. Wanna flash an older rom just use older kernels)
Yes I know that till JVU you could use DamianGto's kernel and that's it but its not going right with JW4/5.
So, after you flashed a GB rom for example DMORE 3.3 (JW5), flash (via odin) DamianGto's GTO Tornado aureus gold kernel (it's 2.3.5+ kernel) [its not working with jw4/5 roms) ( http://damiangto.emc2production.org/viewtopic.php?f=7&t=818 )
After flashing GTO's kernel go to recovery and convert everything ti ext2, and for converting /system you have to reboot the phone.
After that go again to "downloading" mode and flash HARDCORES jw4/5 kernel (extremley important- only hardcore and GTO kernels works with ext2, but only GTO's one supports ext2 convertion.
* if you are installing. For example jw1/jvu/jvz and etc rom you can use clean GTO's kernel without any overflashing.
Enjoy!
Credits:
DamianGTO
HardCore
Sent from my Trasnformer Prime.
Nobody intrested?
Sent from my GT-I9000 using xda premium
I did this a while ago with one of damian's newer kernels, but I found out his "ext2" was actually just ex4-no journal (if i remember correctly... it was a few months ago)
However, I did the same thing with a froyo speedmod kernel (the one's with configurable lagfix - it might have been called ultimate lagfix) and then reflashed a proper gingerbread kernel - and got ext2 working awesome.
I like ext2, but I have had corruption so many times from it...
It is ok if your rom/kernel is completely stable and doesn't have reboots (unsafe reboots = sooo much corruption). Also you may get corruption if you do a battery pull (sometimes my battery falls out when i drop my phone - might be due to the third party cover).
The best thing about ext2 imo is no wasted space on journaling (maximises onenand size like rfs). Performance is a little better than ext4 and about the same as ext4 no journal.
I used to swear by ext2 but nowadays I just use rfs for stability (combined with data/data symlink, and moving & odexing important apps to system (faster onenand). filesystem lagfixes aren't as beneficial as in froyo - it only makes a difference in a few circumstances - generally heavy write operations.