Jim's Depository

this code is not yet written
 

My EEE PC is nearly a 900A, it was a bit crippled to be a super lower than low end Best Buy machine.

First I will create a nilfs2 rooted system on an SD card to verify the steps, then I will migrate that to the internal flash. I am running 2.6.30 with no init ramdisk. Most of the important bits are compiled in, some fringe stuff is a module.

  1. Read about aligning filesystems to flash erase boundaries. I have no idea what my device’s erase block size is, but surely it is a power of two and less than 128k, so I will use 128k. I can conceive of a test I could write to establish this, but will not do it.  Go read Aligning filesystems to an SSD’s erase block size | Thoughts by Ted to learn what I know.
  2. For some silly reason, my internal drive is sdb and my SD reader is sda. Keep that in mind, don’t trash your system if yours is different.
  3. Per Ted’s thoughts (see above) I did an fdisk -H 224 -S 56 /dev/sda and then created three partitions. A /boot at the front, this will be ext3 for grub’s sake, a single track partition 4 typed as 0xef for the BIOS quick boot, and the rest in the middle as my nilfs2 root. (I am willing to believe that this is a bad idea and that the GC of nilfs2 might be happier if I put my log files and such in a different place from my static files, but oh well.)
  4. mkfs -t nilfs2 /dev/sda2 is amusingly fast.
  5. Mount the new root on /mnt and the new boot on /mnt/boot
  6. debootstrap –arch i386 lenny /mnt YOUR-PACKAGE-SOURCE (find that from your /etc/apt/sources file) (I have to do this twice, the first time it complains that Packages.gz is corrupt.)
  7. chroot /mnt  this moves you to the new system. I “touch” a file at the root to identify it so I can tell where I am later… touch /SDCARD
  8. exit to leave the chroot.
  9. cp /boot/*2.6.30 /mnt/boot/  – you’ll want your kernel
  10. cp -arv /lib/modules/2.6.30 /mnt/lib/modules/2.6.30 – and it will want its modules.
  11. cp /etc/apt/sources.list /mnt/etc/apt/sources.list
  12. chroot /mnt
  13. aptitude update
  14. aptitude install locales  (we need to fix that storm of locale errors pending)
  15. dpkg-reconfigure locales (I choose nothing.)
  16. aptitude full-upgrade
  17. aptitude install openssh-server
  18. aptitude install nilfs2-tools (sad, 100MB of crap to install this)
  19. aptitude install grub
  20. mkdir /boot/grub
  21. leave the chroot and get some config files
  22. cp /etc/network/interfaces /mnt/etc/network/
  23. cp /etc/hostname /mnt/etc/
  24. cp /etc/hosts /mnt/etc/
  25. reboot, catch the boot at grub and change to the new root
  26. grub-install /dev/sda  (DANGER! This make break going back to the internal, since I used the internal grub to get here. Maybe manually make the /dev/sda* nodes so grub will work before the reboot?)
  27. Here goes… time to repeat in reverse to install on the internal flash.
  28. All is good. I am confused why my menu.lst file needs root to be (hd0,0) when I am on sdb, but I swapped the SD card for a blank one and I can still boot, so I’m not getting grub bits from there. Probably some BIOS stunt.
  29. Get the nilfs2-tools from squeeze, the one in lenny is too old to work.
  30. The kernel command line option root=UUID=xxxx or root-LABEL=xxxx don’t work because they are not kernel options, they only look like it and are handled in some common initrd programs.

After several days of use I can add:

  1. It feels better than the old ext3 install. That is a terrible metric, I’ll have to do something more rigorous when I get home.
  2. As installed it doesn’t reclaim disk space, it just fills up. If I manually run the nilfs cleanerd then it does reclaim space. For some reason the one Debian starts doesn’t work.

After 25000km of travel with the a nilfs2 root I have to say I like it a lot. Now to figure out why the Debian start of the cleanerd doesn’t reclaim space.

Hi Jim,

I noticed the same problem with the nilfs_cleanerd. Upgrading (from source, in my case) to nilfs-utils 2.0.13 solved the problem for me.

Niek
Flash erase block sizes are typically 4MB or a near power of two these days - pretty large.

Newer, more advanced SSD controllers such as those on the Intel SSDs make this irrelevant by being intelligent about small writes, but with SSDs like those on the Eee PC, you are stuck with erasing and rewriting entire 4MB or so block for small writes.  Hence why Flash writes are only high performing when writing 4MB or more.