Historically, on *nix systems, the reserved filesystem space wasn't intended primarily for performance reasons and has little to do with fragmentation*. The concept was to provide systems administrators with enough space to manage things when the users fill up the disk.

Remember, on [large, multi-user] *nix systems, many files are opened and written to during normal system operation or the login process. This is especially true in a windowing environment (ie., Openwindows, Xsgi, etc.). Without this reserved space, it can be very difficult to login as root and do anything (ie., compress files) to make the system useable for the screaming hordes. When a disk is "full" you still want log files to continue to be written...if login can't write to wtmp, it's not pretty. (Welcome to a good description of my day job!).

With the introduction of "modern," "high-capacity" drives (circa 1992), the historic percentage of space reserved for root has grown to a huge size. I typically cut that down to a small number of blocks, but don't set it to zero. On my personal systems, I'll set the reserved size to zero for "data" volumes, but not for the partition that holds /var, /, or /etc (if they differ).

Oh, by the way, I also run ext3fs on the internal sd and removable sd cards in my N810.

* Since historically (ie., in things like the Berkely FFS, UFS, ext2fs) there's no "defragmentation" command under *nix, so the presence of reserved space still doesn't allow the end user--even root--to defragment the filesystem. I don't consider ufsdump/newfs/ufsrestore to be a "solution".

As a long time Unix administrator, i can say that having a little extra space for root only has NOT proven valuable. The primary command to make new space is not gzip, or even bzip2, but rm, which is faster and doesn't require extra space. Having the user's write(2) fail is bad, and it doesn't matter if 5% of the disk is free or not. So, i maintain a margin. But if 5% is reserved for root, then two margins are maintained. That's double taxation. Besides, these days one can create a RAM filesystem for temp space. My desktop has more than a gigabyte of RAM that could be tapped.

Besides, on larger multiuser systems (eg: the n800), there are multiple volumes. Just because one drive is full doesn't mean they all are. That said, the Unix 'sort' command could fill three filesystems with a single command: /tmp, /usr/tmp and ".".

OK, so it's been a couple months. That thing i was trying to avoid actually happened. My ext3 filesystem has become corrupt. First symptom: media player couldn't find the next audio track - and the book was just getting to the exciting part.

I rebooted, and unmounted the SD card. e2fsck fixed some errors, then aborted with "short read". I thought that meant that there was at least a bad block on the card, but dd could read the entire volume, and 3 runs of badblocks didn't find anything. I ran e2fsck again, and it got further, making some changes. Then it got a segmentation violation. That's repeatable.

I've got a USB SD card adapter, so i mounted the card on my x86 linux desktop machine. It can read the card - dd reads the whole thing (only a little quicker than the n800 can). But e2fsck there says that the magic number is not recognized. Oh. Some byte order problem? I dunno. The Arm is not the same byte order as the x86.

So, i'm back to plan B. For some reason, the n800 mounts the corrupt filesystem. Plan B is to copy as much as possible from the card to backup, reformat, and restore. Fortunately, the little files (text, etc.) are the important ones. The big files - audio and video, are never edited on the n800, and so are available on the desktop, if i want them. In fact, a list of directories is enough to restore these. The first attempt at backup failed. There's a directory loop, and the backup keeps cycling through the same files... But it appears that most or all the files will be recoverable. Last week's backup will not be needed. A good thing, since lots has happened in the last week.

No idea what might have caused the error.

My friends complain that it is impossible to mess up a flash drive.

Backup, reformat with badblocks check, restore. Back on the air. No media errors found.

It has happened yet again. Current idea is that the little tab that holds the 'internal' SD card in slides free, causing intermittent contact. e2fsck crashes with seg fault. Might like to debug e2fsck, but am reformatting card. At least there does not seem to be anything wrong with the card.

The n800 does not boot with a corrupt internal SD card. What does it use it for? Well, it *might* use it for VM, but even if i've turn that off, it won't boot with a corrupt card. That means i must at least format it in the external position. Wasn't there a possible bug having to do with large SD cards (16 GB in this case) and the external position? Or is that fixed? I've reflashed with the latest.

If you think the tab might be sliding, try a piece of tape to hold it in place.

How do you use the noatime option? I know how to do it in my /etc/fstab file, but It was my understanding that under OS2008 the fstab file was ignored. Am I wrong and all I gotta do is edit my fstab, or is there more to it than that?

Actually ARM can do both and on our tablet and most other ARM based systems it is same byte order as x86 - little endian (that is what the 'l' in armel means, armeb is big endian).

You should provide any such options during boot time since thats when the partition is mounted first. Check the fanoush initfs_flasher for bootmenu.conf examples. Careful with any flashing though.