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).
I want to be able to securely delete files(overwrite the whole file at least once) on my s3. I tried to install the app undelete which also has an option to securely delete files. But when I start the app it complains about not finding any fat formated file system. I also tried shredroid but this program crashes on startup, maybe because it also expects a fat file system? So is there a working way to secure delete files on the s3? It doesn't have to be an app, if there is some linux utility like srm compiled for android that would be great.
There's an app called Secure Deletion for Android in the Play Store that should do what you need. No free version, though, and it only has one review and 50+ downloads. FWIW, the single review was 5 stars. I'm gonna keep looking because I would like the same thing.
From what I can tell, stuff like that wont work on our devices' internal memory due to the method samsung has used to grant access to the partitions. Undelete never worked on my Xoom because of the same issue, possibly due to the fact both devices utilize MTP. However, it should work on any external SD cards you may have, however that is just me speculating as I have not tried it.
Sent from my SAMSUNG-SGH-I747 using xda premium
d3athsd00r said:
From what I can tell, stuff like that wont work on our devices' internal memory due to the method samsung has used to grant access to the partitions. Undelete never worked on my Xoom because of the same issue, possibly due to the fact both devices utilize MTP. However, it should work on any external SD cards you may have, however that is just me speculating as I have not tried it.
Sent from my SAMSUNG-SGH-I747 using xda premium
Click to expand...
Click to collapse
Now that you mention it, the internal storage is mounted as a FUSE filesystem, not the expected ext3/4, so it's probably because it's a "fake" filesystem. I wonder if there is a way to access the raw physical filesystem (/data is ext4, which should be compatible with most secure delete apps) instead of the userspace filesystem.
EndlessDissent said:
Now that you mention it, the internal storage is mounted as a FUSE filesystem, not the expected ext3/4, so it's probably because it's a "fake" filesystem. I wonder if there is a way to access the raw physical filesystem (/data is ext4, which should be compatible with most secure delete apps) instead of the userspace filesystem.
Click to expand...
Click to collapse
Thank you. Couldn't remember what it is called. But that is exactly the reason it can't find it with the app. Also, if journaling is enabled, then a secure delete still wont work on ext3/4. This isn't a bug, its due to the way ext with journaling handles reads/writes.
Sent from my SAMSUNG-SGH-I747 using xda premium
Anyone know why it's mounted via fuse? The same files are also available via /data/media and /data is mounted as ext4. Maybe it would be possible to unmount the fuse filesystem, remount the data filesystem as ext2 (no journaling) and then run some secure delete program?
octapod said:
Anyone know why it's mounted via fuse? The same files are also available via /data/media and /data is mounted as ext4. Maybe it would be possible to unmount the fuse filesystem, remount the data filesystem as ext2 (no journaling) and then run some secure delete program?
Click to expand...
Click to collapse
It's because of the MTP. If it were mounted as a normal filesystem, you could use USB Mass Storage, but you would lose access to all of your internal storage while it was in UMS mode.
Also, I don't think you can mount one filesystem as another, so mounting ext4 as ext2 will possibly corrupt your data. What you could do is mount the ext4 filesystem with the journal features turned off (which is practically the same as ext2 but better), then secure delete.
The issue for me is, that task seems a lot more involved on a phone/tablet than it is on an actual computer. Not sure if it would even work. And if you want to secure delete every time you delete something, that's a whole lot of effort to go through. Of course, if you want it deleted that badly, it's probably worth it to you.
I just got a Nexus 4 and have found to my despair that it doesn't have Mass Storage Mode due to the sdcard becoming integrated with normal data.
I really want Mass Storage mode, as I use my phone as a memory stick for various educational purposes, including running various executables directly from the Mass Storage.
Is it possible to create a 1GB, or so, FAT32 partition from the normal ext4 space and allow that to be mounted as Mass Storage?
If someone could point me in the right kind of direction for that, I would be much obliged.
This would require much more work than you would think. You can't just go around changing partition sizes and layout of the nand without the bootloader throwing a Wobbler.
I mean it probably could be done with some extensive work but it means you probably wouldn't be able to use fastboot anymore because the offsets would be wrong
Sent from my Nexus 4 using xda app-developers app
I see, well that's disappointing. I really used mass storage a lot and media transfer doesn't cut it for my needs. Damn.
Yes, this would be possible. However, I haven't done it personally and can see it being a little bit involved. From doing a search, it doesn't look like anyone has approached this either.
Creating the image is the easy part. But to replace the stock fuse setup / supplement it gets tricky. You'd need to extract the ramdisk from your boot and make some changes there at the least. Further, you'd probably have to decompile your framework to modify res/xml/storage_list.xml.
Overall, I think it's doable but would require some research comparing with sources for other devices (with SD cards). I guess it depends on your level of aptitude / desire. Might be better off attaching a usb stick to your keychain.
To get the ball rolling, here's a way you could create a vfat image:
Code:
dd if=/dev/zero of=/data/sdcard.img bs=1M count=1024
mkfs.vfat /data/sdcard.img
That would write 1MB of 0s 1024 times (1GB of 0s) and then format it as FAT.
Perhaps you could research having that "partition" be an add-on, supporting UMS, while still maintaining the default fuse setup.
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