I don't really know about reiserfs, however, jfs is supposedly faster than ext2/3 and the xfs is able to handle larger files and is generally better at doing it than the other 2. I'm tempted to go with jfs when I install some variant of ubuntu...

Some links on the subject:

http://www.linux.com/feature/57788
http://www.linuxquestions.org/questions … t3-434549/
http://arnofear.free.fr/linux/files/con … bench.html
http://www.debian-administration.org/articles/388

In the last link, the quote "Ext3 has the worst inital capacity (92.77%), while others FS preserve almost full partition capacity (ReiserFS = 99.83%, JFS = 99.82%, XFS = 99.95%)" confirms what I was talking about - ext3 will cost 7% more of the disk at the initial partition, or 280 MB on the eee's 4 GB disk.

Reiserfs has:
PRO:  Better performance on small files and in disk space efficiency.  Also, from time-to-time ext3 will stop the boot up and perform its lengthy disk check; I think that's its legacy ext2 property.

CON: Lacks active development; issues with administration and upgrading because Linux distributions don't use it by default.  Ext3 is probably a more conservative/robust FS.  Reiserfs will use a little more cpu in disk operations.  Mounting and unmounting take longer.

On the whole, having read the comments above and the articles, together with my experience with Suse's reiserfs, I think I favor reiserfs over ext3 by 70-30, say; I want the 280 MB back...  Perhaps with a small ext2 partition for /boot.   If one were concerned about system administration and upgrading, sticking with ext3 would be the more conservative approach.

Suse gave up on reiserfs because its development had stagnated (Hans was intransigent about development to reiserfs v. 3.  reiserfs v. 4 has its own problems.) and other Linux's did not use it.  For the purposes of a tuned-up eee running Ubuntu, however, these issues don't matter, seems to me.

Discussions of this issue on-line are endless...

Last edited by SmallFootprint (2008-01-23 12:37:36 am)

I have used reiserfs on multiple distributions for system and media partitions. For two or three years, I ran a two partition reiserfs raid0 with the Linux kernel raid (md), never having problems. reiserfs did seem noticable faster than ext3, disk checks anf formatting were significantly faster. Also, in my experience, Linux deals with moving mount points across diff filesystems fine (presuming you dont mess up fstab or file permissions).

File systems are implimented in the kernel, either as built-ins or modules. As such, it is not a distribution specific capability. However, because many distributions are based on modular kernels in order to be able to support ALL x86 hardware with one setup, you may have to load a module from userspace (if it is even built and available). If you are using reiserfs for root, and a modular kernel, I imagine you would have to build the fs modules into an initrd. Also, dont forget you would have to change fstab.

I usually build monolithic kernels, with all filesystem code built-in, and boot with grub so initrd stuff isnt a problem.

robin wrote:

I can't see the need for a journaling FS on flash storage on a device with a built in UPS (battery).
Seems like unnecessary overhead to me.

Magnetic hard drives, like flash-based SSD, are also non-volatile. The issue is with how the system handles data write and transfer operations, specifically what happens if one of these operations is interrupted. The loss of data is a software issue, not hardware.

A laptop is precisely the type of environment journaling filesystems were meant for. Batteries die, and eventually fail. Sudden shock can disconnect a battery, or cause it to fail outright. Modern operating systems depend on hundreds of files to exist in an uncorrupted state just for basic functionality. There is a reason both Microsoft and likely all mainstream GNU/Linux distributions use journaling file systems as default recommendation for partition formats.

Early generation technology is prone to failure. ASUS has likely produced millions of Eee PC systems, so there is bound to be MANY failures. This isn't unusual, or even from bad decisions on the part of ASUS. There's no way of knowing if SSD failures are even caused by heavy disk writes, as opposed to manufacturing defects. Because there is already a risk of data loss from SSD failure (be it from heavy disk writing, or from being first generation mass produced SSD technology), I do not think adding another problem, like a non-journaling file system on a battery powered general use computer, is the answer.

Please see this post for ASUS Support's position on high disk write software:
http://forum.eeeuser.com/viewtopic.php?id=11802

Last edited by rmrubin (2008-01-26 8:56:43 pm)

robin wrote:

* benefits are not corrupting that gif that is currently getting written to your browser cache when the power fails.

...or autosaved revisions of a school paper im writing (if not the whole file), the last few notes or test values from a project I am saving, a pic I am saving after mindlessly editing for 20min, a streamed file with external logger values, a very large file being copied from someone elses usbhdd to my usbhdd... I do more than just view gifs on the web. Eee isn't even especially great for that, considering the res. I just like the idea of knowing my data is there when I get the system back. I dont mind the cpu overhead, it seems to do everything quick enough even at 650MHz.

And I actually do have interest in using Eee for embedded control, logging and interface applications. Its size/power/storage specs beg to be used that way. Maximum levels of system and data recoverability in the event of a failure is not an unusual goal for such applications. I definitely plan on using it to program/debug microcontrollers. Losing a file's worth of code could be tragic, for the moment. Pray to voodoos the db9 and db25 usb dongles work.

I also have delusions about running CAD/EDA apps on my Eee, so you may just want to ignore me outright. CadSoft EAGLE schema and pcb editors in XP weren't so bad. Dia and GIMP were okay, too. I definitely plan on using it for more than a web/pdf/doc viewer.

robin wrote:

rmrubin wrote:

And I actually do have interest in using Eee for embedded control, logging and interface applications.

Ahhh.  Yes it makes sense for this kind of use.

Has anyone looked at the ordered journaling mode of ext3?  This is the mode where only metadata is journaled.  Should be faster and less resource intensive due to data not getting written twice.  Might be a good balance between safety and overhead.

My own opinion is that journaling is essential, particularly on a laptop for the reasons given above.  Things do get corrupted with a system crash, essential system files included.

"ordered" mode, I think was the default, but I can't recall precisely what that was for xubuntu.  On my Suse linux system, ordered is the default.  (cat /proc/mounts gives the answer).

For me, the compelling reason for reiserfs was saving 0.5 GB of disk space (ordered or otherwise, ext3 still consumes significant disk space when formatted; those inodes I gather).  This is not just 0.5 GB out of 4 GB, but I think of it as 0.5 GB out of the space that's available for the user after system install.  That's 0.5 GB out of 1.5 GB; formatting reiserfs increases available user disk space by 30%!

The system does seem a little faster, disk wise, although the flash disk is pretty darn fast as it is.

I agree with the notion of a monolithic kernel for the eee - there is not much reason to have the full collection of kernel modules (thinking of my ubuntu installation here).  Although perhaps for some things (madwifi?) a module might be better for resetting hardware in a peculiar state.  Having been down that sort of road many times, however (to contradict myself...), I strive to stick to stock distributions whenever possible; much less overhead in system administration, updates, upgrades, etc.

The adventurous can replace these four steps

(b) preserve the entire filesystem to a back up media.
(c) boot to a "rescue" or live CD system.
(d) reformat the disk for reiserfs, which should preserve the MBR.
(e) copy the entire filesystem back to the newly formatted disk.

with running convertfs (after booting from a rescue/live CD).  It's not been updated in three years, but it's still frickin' amazing.  It converts between linux filesystems by moving files into a sparse disk image of the new file system.  Then it turns the filesystem inside-out (that's how I think of it anyway), to write the disk image file to the physical disk.  It's able to create an image file the same size as the device because sparse files avoid allocated any space for blocks that aren't actually used.

You just need usb filesystem, ehci, uhci, mass-storage and hid built-in. You're never going to be unloading those, and you might be loading filesystem mounts from a usb device (ninja adventures, who knows), so built-in makes things neater. Everythng else you can do modular as you need it, or built-in if you know your setup will use it.

The default Xanadros kernel config actually did have EVERY usb device driver built as a module. I wonder how good the kernel module auto-loading actually is, if it does usb devices at all.