ext2 vs ext3 vs ext4

All of the distros for the RP are using ext4 on the SD card, all the ones I have looked at anyway.

They are doing this because of the supposed advantages of journaling, however I had a reminder a couple of days ago not to rely too much that journaling will save the day.

The power went off my RP unexpectedly, and even after I had done a filesystem check, I still had some corruption. A couple of files were truncated, due to the filesystem buffers in RAM being unable to flush completely.

Also, journaling is bad for Flash memory as there are more writes to memory. It is also slower.

Then there is Execute In Place (xip) suggested by technosaurus. This will be very good for a system with not much RAM. Xip is only available for ext2 I think.

Puppy will do a f.s. check at bootup if there was an abnormal shutdown. This is done by creating a mini-Linux in a ramdisk, chrooting into that, unmounting the main partition then doing a f.s. check, then reboot. This all happens automatically. Fortunately, as I have compiled my own kernel, I set the ramdisk big enough (I think).

All of the above indicates to me that ext2 is the best choice for the RP. My kernel also has enabled ext2 support, with xip enabled. So, I reckon this will be the next thing to try.

---

Comments

xip
Username: BarryK
From the official kernel documentation: [i]This implementation is limited to storage devices that are cpu addressable at all times (no highmem or such). It works well on rom/ram, but enhancements are needed to make it work with flash in read+write mode.[/i]

re xip
Username: BarryK
"According to this page, ext2 and ext3 also support xip: http://en.wikipedia.org/wiki/Comparison_of_file_systems ...that is a mistake?

aXIPfs
Username: Ted Dog
"open source xip filesystem http://axfs.sourceforge.net/ was learning about xip and came across this. looking foreward to mele version. If we need to roll with wolf does it go on the target machine or is it cross compiled? never could grasp how to start development with wolf.

Re glibc in initrd
Username: BarryK
"K Godt, [i]Also glibc-2.6.1 is much smaller for the initial ramdisk[/i] Puppy doesn't have glibc in the initrd, everything is compiled statically with uClibc or dietlibc. However, Debian and Ubuntu do have glibc in their enormous initrds. Note, our SD card installation of Puppy for the RP does not use an initrd at all. Nor does Debian for RP.

ext2 is best for Flash
Username: BarryK
"For Puppy booting off Flash drives, I have always used ext2 for the save-file. Always, ever since the project started. Others lobbied for ext3 (and recently ext4) support, so I obliged them. However, I recognised that the journal in ext3 and ext4 offers limited protection, and my reconsideration in this blog thread reconfirms my opinion. A journal at best only offers partial protection, unless it is able to mirror all of the RAM filesystem buffers. Actually, I think that I read ext4 is capable of doing that, but that option is not used due to the performance penalty. So, a journal gives you a false sense of security. A journal, by its very nature is going to hammer the Flash very hard with frequent writes. SD cards are going to fail very quickly. In the current situation, booting off a Flash SD card, with a "full installation" of Puppy (no save-file, no initrd, no unionfs/aufs), the situation is worse, as all writes go directly to the Flash memory. Even /tmp. The RP has so little RAM that I haven't even mounted a tmpfs (filesystem in RAM) on /tmp. Then there is the swap partition on the Flash drive also. I should mention that all those other Flash filesystems, FFS2, JFFS2, LogFS, YAFFS, are for Flash NAND and NOR memory (MTD) chips, not for block-filesystem Flash drives such as SD and CF cards (these have their own intermediate electronic hardware in the card, and may include wear-leveling). A note for those who choose ext3 or ext4 for their save-file when booting off Flash drive on a PC. The journal is in the save file, and the save-file is copied to RAM (if sufficient RAM). All work is done in RAM, with periodic flushes to the Flash drive. This makes the journal basically useless. In the case of the save-file not being copied to RAM, then the journal will work, but your Flash memory is going to get hammered. I should point that my recent experience with file corruption on my SD card went "unreported". The journal appeared to have recovered everything, no errors were reported at next bootup. It was only because I didn't believe that recovery could be complete, that I checked the files that I had been working on at the time of power failure, and found a couple of them were truncated. Read this to learn more about how journaling gives us a false sense of security: http://lwn.net/Articles/349970/

PUPMODE=3 ??
Username: K Godt
"QUOTE : In the current situation, booting off a Flash SD card, with a "full installation" of Puppy (no save-file, no initrd, no unionfs/aufs), Wondering why PUPMODE=2 and not PUPMODE=3 possible ? Debian limitations ?

Re PUPMODE=3
Username: BarryK
"Yes, I don't see any reason why we can't do PUPMODE=3 on the RP. I have have been taking small steps, just doing it the same way as the other distros so far. PUPMODE=3 would give us an initrd and a layered f.s., which means that we can load and unload sfs files. I will probably experiment with that a bit later. We would also have the choice of saving the session to either a save-file or the entire partition.

SDcards
Username: mavrothal
"I'm using SDcards with my XOs 4 years now, to both hold the OS and the swap partition. The story about the cards wearing off from the read/writes is pretty much a myth but has several caveats. The modern cards are pretty good in wear leveling and ext2 or ext3 does not make a lot of difference in that front (~20% more writes) if the card is "good" and "properly formatted". The older of my cards runs for 3 years now without any issues. What is really important is the card characteristics, mainly the simultaneous open allocation units, and if it is properly formatted to the erase block boundaries. Linux formating utilities are doing a terrible job on this and can exponentially increase read/writes and decrease card performance (thus, although user-friendly, I think is a bad idea to to distribute the ARM OSs as dd images even if properly formatted your your specific card). Unfortunately the crucial card characteristics (page and erase block size, open allocation units etc) are very inconsistent even for cards of the same brand and type, and they are not reported anywhere. Even if known though, formating utilities just ignore them. [url=https://lwn.net/Articles/428584/]Here you can see a relevant LWN article from the Linaro project developers about optimizing SDcards for Linux. At the bottom of [url=https://wiki.linaro.org/WorkingGroups/Kernel/Projects/FlashCardSurvey]this page there a list with various SDcard characteristics (and their huge diversity), though unless you have the exact same card, is not much help. Finally, [url=http://www.olpcnews.com/forum/index.php?topic=4993.0]this post has some formating instructions based on the card characteristics and at the bottom, links to the (a bit old by now) compiled flashbench utility that can tell you the important characteristics of your specific SDcard.

Keystroke / timer for save
Username: Tony
"Re wear and tear on flash drives would it be possible to count keystrokes? If so perhaps there could be a setting to say "After so many keystrokes commit to flash" in addition to the normal write to flash timer?

keystrokes
Username: K Godt
"Quote : count keystrokes? I think some people would like to tar and feather you for that idea . It may be possible to use the kernel/drivers/input/evbug.ko if compiled and shipped with the distro, that would make it possible to log or show up in console or /var/log/syslog.log all keystrokes even your PINs and Security Passwds ... :cool:

More on journals
Username: BarryK
"While I'm bashing journaled filesystems, a couple more points. The Linux documentation informed us right from the start that journaled filesystems are incompatible with loop-mounted files. I can see why. The journal is being maintained inside the file, not directly on the physical disk as it should be. This means that the protection that the journal offers in the case of a crash, is absent. So, another reason why ext3 and ext4 are pointless, or perhaps nearly pointless, for our PUPMODEs that have a save-file. Regardless of whether the save-file is on USB or hard drive, the same problem exists. Then there is speed and size. A journaled f.s. is inherently slower, and the journal occupies a very large portion of the f.s. storage space. Heh heh, you guessed it, Puppy alpha3/beta1 for the RP will use ext2!

ext2 vs ext3 vs ext4
Username: ttuuxxx
"I only use ext3 on all my linux hard drives, I won't use ext4 because it doesn't work on older puppies eg puppy2,3,and early 4 series, ext 3 will work with all of them.

Flash card life
Username: BarryK
"mavrothal, Yes, I am wondering whether I should be that concerned about number of writes these days. I did read recently that there is an enormous difference in the quality of SD cards, which translates into lifetime. The order of 50x. One Microsoft link stated that using a top quality USB Flash pen drive as cache, it will last "up to" 10 years. But, if you divide that by 50 for the worst card, then you get about 2-3 months. That link you posted: https://lwn.net/Articles/428584/ ...very interesting, particularly that partitions should be on 4MB boundaries. My SD card partitions are not -- I used a Rasbian SD image as the basis of mine, I think, other Linux distros for RP will be having the same potential problem. I might as well align the partitions on 4MB boundaries for my SD skeleton image. Also, when using 'dd' I should set block-size to 4MB (instead of 1MB that I currently use).

Keystrokes
Username: Tony
"Hi K Godt, lucky I am a Cloud A.I. and not a real person 8-) Yes I see what you mean about evbug.ko but I was thinking of something simpler, as last time I mucked around with interrupts it was on an 8085 board and I had to write my own code just to read the hex keyboard! I was thinking about adding code to keyboard interrupt routine that increments a counter that would then trigger a different interrupt to operate the write to flash. Probably way to low level stuff to be easily do-able?

Reiserfs
Username: Jota
"Hi! While we are at this fs subject, I would like your opinion about reiserfs 3.6 compared to ext2, specially on older hardware, eg. IDE drives. Is reiserfs much slower/worse than ext2?

advantage of ext4
Username: jamesbond
"In ext4, journalling can be turned off: [code]tune2fs -O ^has_journal /dev/sda2[/code] The main advantage of ext4 against ext2 is that ext4 uses "extents" to manage file allocation instead of bitmaps, providing better performance when transferring large files.

Tags: puppy