Linux, politics, and other interesting things
I’ve just been working with a Flash device used as /dev/hda (the root filesystem) for a router. The aim is much the same as with my idea of using an EeePC as a router . The client in question may consider the EeePC for future deployments but are concerned about the ability of ASUS to supply when needed. The typical customer at a computer store probably isn’t going to be too upset if they have to order their computer and wait a week, but when rolling out a network for a few corporate offices it’s a major problem if there aren’t enough devices to get them all online at once!
One problem I encountered is that the default configuration had IDE DMA enabled and this didn’t work well on the system, rumour suggests that it might be related to the bridge chipset used to run the PATA controller which talks to the device that houses a SD Flash module and connects to the IDE cable. But I discovered that it would work reasonably well (at about 75% full speed) if I turned off DMA. When I run the Flash device with no DMA and 16bit IO I get about 2.4MB/s, I get 4.4MB/s if I use 32bit IO, and 6MB/s with occasional system hangs if I use DMA.
The machine in question is running CentOS so the trick was to run hdparm early enough in the boot process to turn off DMA before the machine could hang. In most cases the machine would lock up solidly when udev was started.
So I added the following lines to the start of /etc/rc.d/rc.sysinit (just after #!/bin/bash):
/sbin/restorecon -R /dev 2> /dev/null
/sbin/hdparm -d0 -c1 /dev/hda
Now the system seems to be working correctly.
The flash device seems like a good concept, no moving parts means less heat and more reliability, and the seek time is really good. But slow performance for bulk IO and problems with DMA increase the difficulty of implementing it. The advantage of having it in a pre-packaged device such as an EeePC is that it’s all one unit that is known to work together and has the drivers configured.