After some research I don't think ext2 is a good choice for SD card partition Type. And ext3 is catastrophic. Ext2 tends to wear off the card with great speed, even with SD cards automatic anti-wear off protections.
Google on the topic and you will see it for yourself. Also Ext2 isn't very optimized for lots of small files. Neither in speed, nor size.

ReiserFS should be far better choice. It has a big edge over ext in terms of small files handling (the devs behind reiser stress quiet often on that). It is much more self repairing (I got lots of errors when running e2fsck on the SD card from time to time). It handles wearing off much better.

The only bottleneck I can think of now is the 32MB used for metadata. That's it. Even on empty filesystem you have 32MB used with metadata. On the other hand with 2GB cards costing $20 32MB is not that much.

Only two changes are required.
- Change bootmenu.conf to use reiserfs as parameter for partition type
- Provide ReiserFS support in kernel (either module or built-in)


I tried it, partitioned with reiserfs, modified bootmenu, cloned / and compiled kernel with reiserfs built-in. Boot time seemed a little bit faster compared to ext2 and also it seemed to use about 5-10% less space.

I have just to work out one problem, causing the tablet to hang for a while after loading the blue bar and to restart, which happened on a few occasions and then provide alternative instructions.

I can include reiserfs kernel module in bootmenu installer so no custom kernel would be needed and we have more choices by default. Personaly I think ext3 or 2 is not so bad but still reiserfs might be good to try. Please report how it goes with reiserfs and how stable it is.

Also feel free to post links to proofs of 'catastrophic' nature of ext[23] filesystems :-) IMO anything is far better than plain FAT which is the default for memory cards and manufacturers still give lifetime warranty for that. Also most devices (cameras, PDAs,..) cannot afford write caching at all (due to possible data corruption on crash or drained battery) so cards should be manufactured with that in mind. I know for sure that all PalmOS based PDAs do not use any write caching at all so FAT table and data blocks is updated with every VFSFileWrite call. ext2 or 3 filesystem mounted with asynchronous writes is heavens compared to that behaviour.

The other bottleneck may be RAM usage and behavior in out of memory situations. Last time I checked ReiserFS code was much bigger and its realtime memory usage may be also higher. This may not matter with N800 but with 770 every nonswappable RAM page taken by kernel hurts.

Right now I am on the Windows box at work, so can't do much, but when I get home I will experiment with one ext2 and one reiserfs filesystem. Comparing disk space usage, speed, resources usage, etc.

As a follow-up to my earlier-voiced appreciation for this excellent hack of Milhouse's (an appreciation which is noways diminished by the following):

I have just purchased a 4-gig SDHC card and have again re-cloned my OS onto it. (My last such cloning was on a 2-gig SDHC card.) But in this instance, I've discovered a possible pitfall for the unwary (such as myself). The instructions in the following site referenced in step 5 by Milhouse state as follows:

umount /media/mmc1
sfdisk /dev/mmcblk0

This will prompt you to give a partition size for each partition; we'll make 2 partitions. The first will be FAT16 (type 6) - the partition we see when we connect the 770 to a computer with USB. The second will be our boot partition, where our home directory is stored. I have a 2 gig MMC and used the following layout. Note, the 15000 refers to cylinders, each of 32 KB, so 15000 cylinders is 480 MB. So the first partition goes from 1 to 15000 with a partition type 6, or VFAT. The second goes from 15001, to the end fo the disk, so it's about 1.5 gb. The third and fourth partitions are empty.

/dev/mmcblk0p1: 1,15000,6
/dev/mmcblk0p2: 15001,,
/dev/mmcblk0p3:
/dev/mmcblk0p4:


As Milhouse's instructions state, the intent (and result) is for the clone to be installed on /dev/mmcblk0p2, and by following the above instructions, the clone will find it certainly has plenty of space there! In my first try, about 3.5 gigs! (I'd wanted it to have only the intended .48 gigs.)

So, I had to reverse those recommended numbers by giving mmcblk0p1 "15001 ,," and mmcblk0p2 "1,15000,6". I found myself flying by the seat of my pants here (I'm no Linux expert) but to my surprise (and relief) it worked.

I may in fact be completely in error here -- but if so, I've at least ended up with a properly (for me) partitioned card.

Correct, the partition sizes quoted in that wiki page are just one possible example (in this case appropriate for a 2GB card split 0.5GB + 1.5GB), and the figures will be inappropriate for a larger or smaller card.

When you run sfdisk, it will state how large each cylinder is on your card - on my Transcend 4GB card, each cylinder is 32768 bytes. Given that information, you can determine how many cylinders you need for a 3.5GB partition by dividing (3.5 * 1024 * 1024 * 1024) by 32768 - this calculation tells me my first partition would be "0,114688,6" and my second partition "114689,," (ie. all remaining space to be used by the second partition).

Alternatively, you can specify the "-uM" parameter when you use sfdisk so that you can then specify the partition sizes in terms of megabytes instead of cylinders, eg. to create a 3.5GB partion #1 with the remaining space* in partition #2, use the following:

#sfdisk /dev/mmcblk0 -uM

/dev/mmcblk0p1: 0,3500,0C
/dev/mmcblk0p2: 3500,,
/dev/mmcblk0p3:
/dev/mmcblk0p4:

Note: I've used a partition type of 0C on the first partition as this will create a FAT32 partition. When formatting the first partition for VFAT, use "mkfs.vfat /dev/mmcblk0p1 -F 32" if you want a FAT32 filesystem.

* Your 4GB card is unlikely to be 4GB in size as memory card manufacturers tend to use 1000 bytes to a K and 1000KB to a MB notation (rather than 2^10 or 1024 notation). Typically a "4GB" memory card will have between 3.7GB and 3.8GB usable space, which means that if you specify 3.5GB of space for the first partition you'll only have ~0.3GB (or less) space remaining for partition 2, in which case adjust the size of your first partition down by the amount of difference between your real card size and 4GB ie. if your card size is 3.8GB, use a figure of 3.3 (ie. 3.5 - 0.2) to calculate the cylinders, or 3300 when specifying the partition sizes in MB.

Yes, the above should work - it's a bit wierd though, as your first partition is now physically located on the card after the second partition, but that shouldn't be a problem. The only minor issue is that you've specified that partition #1 is a Linux partition (it should be FAT), and partition #2 is a FAT16 (,6) partition (it should be Linux). Again this shouldn't be a problem as I'm guessing the format routines will put the correct filesystem on to the partitions - when you run nupgrade.sh 0 it will put ext2 on the second partition irrespective of what sfdisk thinks the partition type is.

I imagine that sfdisk still states that parititon #1 is Linux and partition #2 is FAT16 even though they've been formatted with the FAT and Linux (ext2) respectively.

Milhouse: I believe you are right in your assumption that nupgrade.sh 0 corrected my mis-designation of the file types for each partition. In fact, my partition 1 (for data) now indicates that it's FAT32.

You may (or may not) though have misunderstood what I perceived to be my earlier dilemma. Partition 1, which is intended to be the FAT data storage partition, was being limited to roughly .5 GB's, while Partition 2, on which the clone resides, was given all the rest of the card memory available, in my case roughly 3.5 GB's. I was thus losing all the useful data memory for which I purchased the larger capacity card. In my earlier dual-boot cloning with my 2 GB card, which I had in my external slot (not the internal slot that currently houses my 4 GB card), I again followed your instructions precisely, but this partition dichotomy didn't seem to occur. (If it had, the Partition 1 data space would again have been limited to .5 GB and the Petition 2 clone space to an unnecessarily large 1.5 GB. But I don't recall that that was the case (unless I didn't notice it, which I doubt). I recall having had an approximate Petition 1 data space of 1.5 GB. So, I don't know what happened in this latter 4 GB card attempt. (I've since reformatted my former 2 GB card, so I can't now check that to be sure.)

I hope I'm making myself sufficiently clear here. If I'd been formatting a 1 GB card, nothing would have mattered, as both partitions would have been the same size. Anyway, many thanks for your response and thinking this through with me. Regards, Jim

Hi Jim

I understood you - the wiki page you followed is using a 2GB card and the figures it proposes for the partitions will create a 0.5GB FAT partition #1 (15000 cylinders * 32768 per cylinder is roughly 468MB), and all of the remaining space (~1.5GB) is allocated to partition #2, which is where the cloned OS resides. Essentially, the wiki page partition sizes are overkill as I don't think anyone really needs more than 0.5GB for the cloned OS partition (IMHO), and the wiki page doesn't allow for any variance in card size.

If you follow my instructions above, you should be able to calculate the correct figures to enter into sfdisk and create more appropriately sized partitions for your needs.

By far the easiest way to create the partitions will be to specify the partition size in MB, and assuming you only want one large FAT partition and the remaining space to be used for the cloned OS I would suggest you use one of the following examples as input to sfdisk (it should be fairly obvious how to adjust the figures to suit your tastes should you want a smaller OS partition - just increase the size of the first partition! ):

1GB Card (~0.8GB real size - partition 1: 0.3GB, partition 2: ~0.5GB):
2GB Card (~1.8GB real size - partition 1: 1.3GB, partition 2: ~0.5GB):
4GB Card (~3.8GB real size - partition 1: 3.3GB, partition 2: ~0.5GB):
8GB Card (~7.8GB real size - partition 1: 7.3GB, partition 2: ~0.5GB):
Note that by specifying ",,," for the second partition, the second partition is created immediately following the previous first partition, uses all remaining space and defaults to the Linux partition type.

Milhouse: Your latest instructions for resolving this problem seem clear and excellent, a praiseworthy characteristic of all your contributions to this forum. Fortunately, however, my fumbling resolution to my difficulties as reported a bit earlier in this thread have achieved substantively the same outcome as you propose for the 4GB card, and as I've already loaded up data on the FAT portion of the card, I'll just let matters stand as at present. However, for others who are perhaps encountering the same problem from the wiki as I did, your new solutions should really simplify things for them.

On my earlier cloning of my 2 GB card, which following your instructions was highly successful -- I've now remembered the reason for that (which I had momentarily forgotten when sending off my previous message referring to the 2 GB card). For that cloning, I hadn't used the wiki instructions for partitioning but instead had partitioned my card using gparted. But for the 4 GB card, I'm currently away from home and didn't have my usual ready access to gparted.

Anyway, problem solved, for myself and I assume as well as for similarly affected others, and again my many thanks. Regards, Jim