You are not logged in.

#1 2007-10-01 14:13:07

keenerd
Trusted User (TU)
Registered: 2007-02-22
Posts: 646
Website

Arch on flash memory

I've been working on heavily modifying an old laptop for minimum power draw.  Currently I'm in the middle of replacing the hard drive with a compact-flash-IDE drive.  No moving parts, no heat, no seek times, no waiting for spin up.

I've found out that Grub refuses to work in this circumstance.  Spent two weeks testing out every possible way of installing Grub, nothing worked.  Tried Lilo this weekend, and the automagic worked perfectly.  The rest of the 'net seems divided on Grub, but save yourself the trouble and go with Lilo.

I'm requesting help to minimize the two drawbacks of flash, limited writes and slow continuous transfer.  Transfer rates can be improved with better flash memory, so I'm buying a card capable of 2.5 Mb/sec.  Writes I'm keeping to a minimum by mounting ext2 and noatime.  Are there more tricks I could use?

All the log files seems to be an issue.  I was thinking of creating a ramdisk and attaching /var/log to that.  I lose all logs on reboot, though.  Is there a better way?

The slow read/write rates seem to really hurt boot time as well as pacman.  The guides I've seen on high speed booting involve custom kernels with no extraneous modules.  Is there another way more suitable to this hardware? 

Pacman is rather hilarious.  It finishes plenty fast, but will spend another 10 minutes writing the async spool out of ram to the drive.  The package cache takes up a lot of space, too.  I can easily fit a full install in 4Gb, less if I remove my worst drive hogs like LyX and Erlang.  I have to routinely clear old packages, though.  How bad is it to keep no package cache at all?  The cache has saved my butt a few times, but it is not worth chewing up a gigabyte of precious flash.

Anyone else try this with Arch?

Last edited by keenerd (2007-10-01 14:14:50)

Offline

#2 2007-10-01 16:09:59

lilsirecho
Veteran
Registered: 2003-10-24
Posts: 5,000

Re: Arch on flash memory

Interesting read on your efforts to use flash for the hdd in the system.

A related application which is arch-based is Faunos which loads a 1GB flash drive with arch packages and provides a boot with USB or DVD into the system.  With enough ram, it can be loaded to RAM, thus eliminating the flash reads and writes after booting.  Without RAM boot, the system has good response time while loaded in FaunOS.  In this mode, flash reads occur.  A save session feature allows writing new session data to the flash unit when rebooting (or during the session).

I recommend your trying FaunOS , perhaps it will give you some ideas about your application or even enhance what your system does.\

Best of luck!!


Sign of the times: Navajo blanket..made in China
Hard work does not kill people but why risk it: Charlie Mccarthy
A man is not complete until he is married..then..he is finished.
When ALL is lost, what can be found? Even bytes get lonely for a little bit!     X-ray confirms Iam spineless!

Offline

#3 2007-10-02 05:14:13

gradgrind
Member
From: Germany
Registered: 2005-10-06
Posts: 921

Re: Arch on flash memory

I would second that. It's not quite the same as running a 'straight' installation, but it does to a large extent solve the difficult problem of the limited write capability of flash memory. Because it's compressed. you can also fit quite a lot in the given space.

I'm a bit surprised you had trouble with grub, but maybe it's something specific to your hardware.

I have an old computer here running a larch-based system (faunos is also based on the larch scripts) from compact flash as a media player (so no writing necessary). Booting is very fast.

And do you really need old log files?

Last edited by gradgrind (2007-10-02 05:16:09)

Offline

#4 2007-10-02 06:08:10

keenerd
Trusted User (TU)
Registered: 2007-02-22
Posts: 646
Website

Re: Arch on flash memory

Before becoming an Arch user, I was a developer for Puppy Linux.  They use a very advanced system similar to what FaunOS is doing, but manage to fit a complete desktop system into 80Mb.   (Complete is a relative word - GCC was a 50 Mb drop in, OpenOffice another 80 Mb.  But much more complete than Damn Small Linux.)

Of course, after I was done adding all my extra packages, I was up to a gig of impossible to maintain applications.  I switched away from Puppy to Arch largely for the rolling upgrades and better selection and support of packages.

I've played the specialized distro game, and I didn't like it.  Its too restrictive.  Maybe if I built my own live CD I'd be happy, but I've have to rebuild it every week to stay up to date.

Running the OS from from  compressed ramdisk is also a trick Puppy used.  But I burn through ram rather quickly.  And even with Puppy, a mere 80 megs, I noticed better performance when the OS was uncompressed to the drive.  MUCH faster boot.  The free CPU cycles and free ram made the system faster more responsive on low ram systems.  The whole point of running from ramdisk is lost the moment you start swapping.

One possible problem with the log files - some are opened before userland scripts can mount /var/log to a ramdisk.  I could symlink /var/log to /dev/null, but that seems a little heavy handed.  Log files are nice things to have.  Right now I use root-tail to always show the last few lines of /var/log/messages.log on my desktop.

I think I've got a new policy on swap space.  There will be a small swap partition, equal to the ram size.  Swapping to flash is bad, so it will normally be disabled.  Swap will be turned on just before running pm-utils hibernate :-)

Offline

#5 2007-10-02 08:58:11

gradgrind
Member
From: Germany
Registered: 2005-10-06
Posts: 921

Re: Arch on flash memory

Doesn't puppy actually copy the whole system to memory? I wonder what other reason there could be for it being slow to boot. With faunos/larch very little memory is lost as the system is (by default) run from the boot device.

Updating software is of course not so straightforward, but is to some extent possible (the overlay files will grow, as will the time required to rebuild them, and a kernel update would definitely require a rebuild of the whole system).
If it is really important to you to keep absolutely everything completely up to date, I suspect a flash based system may not be ideal.

I still don't quite see your problem with log files. Looking at log files from the current session is no problem - in a 'live' system they are just stored in memory instead of on disk, you wouldn't normally need to do anything extra to get this behaviour, it's quite automatic. And how often do you want to see yesterday's log files?

Offline

Board footer

Powered by FluxBB