• Home
  • Help
  • Search
  • Login
  • Register
  Show Posts
Pages: 1 ... 3 4 [5]
61  Hardware and U-Boot firmware / Hardware / Re: Dead SD Card after 3 weeks : caused by Sheevaplug or something else? on: March 07, 2010, 12:47:12 PM
Cool -- sounds like a completely feasible solution for root file systems on SD cards!

Regarding the start time: The init scripts in Debian have a section like this (taken from sendmail):

# Provides:          sendmail
# Required-Start:    $remote_fs $network $syslog
# Required-Stop:     $remote_fs $network $syslog
# Default-Start:     2 3 4 5
# Default-Stop:      1
# Short-Description: powerful, efficient, and scalable Mail Transport Agent
# Description:       Sendmail is an alternative Mail Transport Agent (MTA)
#                    for Debian. It is suitable for handling sophisticated
#                    mail configurations, although this means that its
#                    configuration can also be complex. Fortunately, simple
#                    thing can be done easily, and complex thing are possible,
#                    even if not easily understood ;)  Sendmail is the *ONLY*
#                    MTA with a Turing complete language to control *ALL*
#                    aspects of delivery!

It should be possible to use the Default-Start and Required-Start sections to survive runs of update-rc.d. This should keep you safe until flashybrid is udpated. The next step would probably be to submit a defect with the Debian folks to have this done per default -- given all the problems when starting flashybrid later, doing so sounds like a bug to me...
62  Hardware and U-Boot firmware / Hardware / Re: SD Card problem on: March 07, 2010, 12:07:04 PM
There are other threads around this subject but in a few words, SD cards (and other kinds of "cheap" flash memory) use wear-leveling algorithms that have been designed with FAT file systems and somewhat evenly spread write accesses in mind (like a camera that fills up the card, then all files are removed and everything starts over). The FAT area gets special treatment here (e.g. carefully aligned to erase block boundaries in the default partition layout) and some wear-leveling algorithms also peek into the FAT to find out which sectors are currently unused. Using those kinds of flash memory for a Linux root filesystem will wear them out quickly.

Check out the other threads like this one: http://plugcomputer.org/plugforum/index.php?topic=1074.0

In a nutshell, reduce writes by using "noatime" or "relatime" options, consider using ext2 instead of ext3 and move directories with frequent write accesses to ramdisks (tmpfs). Or, checkout the thread above to see how flashybrid can can automate this, copy files between ramdisk and stable storage and reduce writes to the root filesystem to the extent that all this won't matter anymore.
63  Hardware and U-Boot firmware / Hardware / Re: SheevaPlug USB Power Supply problems. Can it Drive a USB Ext Disk? on: February 20, 2010, 03:04:45 AM
I'm also very interested in the smoke test results. Thanks for volunteering to do all the dirty work!

I've had a few switching power supply failures due to bulging or venting capacitors myself, the last one being an NSLU2 power supply. It's usually easy to put in a new capacitor with better ESR ratings and the power supply will work again. Just keep in mind superpats warnings about the high voltages in switching power supplies! Given the relatively low price of those caps, it makes me wonder why manufacturers are so cheap about them...

BTW, you can usually connect a power supply directly to the USB disk enclosure so you can apply separate power to the HD without having to use a hub.

BTW2, unless you mercilessly overload the PS to the point of explosively venting capacitors, a typical failure pattern will be that the capacitor doesn't stop working right away; instead, it will slowly lose capacity. This process will accelerate as the electrolyte degrades and by the time you notice something, you probably have only a few days left. One of the things you may notice is that the HD doesn't spin up anymore, trying again and again and generating clicking noises as it does so. But even if you disconnect the HD now, the capacitor is doomed and even a normal plug power load will destroy it in a few hours or days. I had the exact same thing happening on a NSLU2 and ended up powering the NSLU2 by plugging a power supply into the HD enclosure (the NSLU2 can actually be powered by the USB port -- not sure if this is the same with the plug Wink

64  Hardware and U-Boot firmware / Hardware / Re: Dead SD Card after 3 weeks : caused by Sheevaplug or something else? on: February 20, 2010, 02:04:09 AM
Looks very intersting, indeed, although it's the other way round for me as I use a spinning HD for root and just want to use the SD card to reduce spin-ups for log writes. And if my SD card dies, I haven't lost anything I value.

The mount tricks used by flash-hybrid seem to be more or less the same that I use. My fstab looks like this:

proc            /proc                   proc    defaults        0       0
/dev/sda3       /                       ext3    relatime,errors=remount-ro 0       1
/dev/sda2       none                    swap    sw              0       0
/dev/mmcblk0p1  /boot                   ext2    relatime,noexec,nodev,nosuid        0       2
/dev/mmcblk0p2  /var/log                ext2    relatime,noexec,nodev,nosuid        0       2
/dev/mmcblk0p3  /var/.mmc               ext2    relatime,noexec,nodev,nosuid        0       2

# Overlay some volatile directories in /var with MMC mounts; I'm not using
# links because MMC cards could be removed, faulty due to wear, ... and I
# want the whole thing to fall back to the hard disk during the next reboot
# in case /var/.mmc did not get mounted.
/var/.mmc/milter-greylist       /var/milter-greylist    none    bind    0 0
/var/.mmc/run/sendmail          /var/run/sendmail       none    bind    0 0
/var/.mmc/run/samba             /var/run/samba          none    bind    0 0
/var/.mmc/cache/samba           /var/cache/samba        none    bind    0 0

The trick is to overlay a directory using the "bind" option. Since I'm doing this in fstab, it happens at the beginning of the boot process right after the root filesystem has been mounted read-write and before starting tons of daemons. That might be one of the problems with flash-hybrid mentioned above -- it might come too late and some files might already be open in the underlying root directory. Other than that, if I would mount a tmpfs over /var/log and other directories, the result would be more or less the same, minus copying things back and forth of course.

As you can see, I'm mounting /var/log directly into a partition while having another partition, /var/.mmc, to overlay the remaining directories with frequent write access. Again, I'm doing this the other way round, pushing frequent writes to the SD card to prevent HD spin-ups Wink

BTW, if you want to remount root with different options, add the mount option "remount". Like so:

mount -o remount,ro /
65  Hardware and U-Boot firmware / Hardware / Re: Dead SD Card after 3 weeks : caused by Sheevaplug or something else? on: February 15, 2010, 03:47:10 PM
I forgot to mention another piece of information regarding wear leveling: Some controllers seem to split sd-cards into fixed wear leveling units for simplicity. An older Sandisk document mentioned 4MB for a wear-leveling unit which, given 128KB as erase block size, means there's only 32 erase blocks that will ever be considered for wear leveling, plus some spare erase blocks.

Adding spare erase blocks, say 3 per wear-leveling unit, those cards end up having around 37 erase blocks per wear-leveling unit. Given this scenario and a lifetime of 10,000 write cycles, you would end up with 370,000 write cycles on a particular wear-leveling unit, not counting additional stress caused by copying around used blocks as part of the actual wear leveling if you're not simply writing to the same sector every time. Not exactly very much...

On my sd-card, I get roughly 900 writes per day for /var/log with a total filesystem size of around 5MB. Being pessimistic (i.e. assuming most writes end up in the same 4MB unit), this might result in a total lifetime of the card of 411 days. The underlying math is, of course, much more complex and depends on the distribution of writes but I assume the 411 days are not too far off in my use case.

Another issue is what happens when power is lost during write access (remember: the sd-card controller typically needs to read 31 sectors, merge the 1 sector you want to write and then flash the full 32 sectors of an erase unit). I recently used the plug to cross-compile a dbox2 PowerPC image (the little plug actually performed admiringly for this task) but a bug in /bin/dash caused all memory to be consumed and left the plug in a vicious out-of-memory-killer loop. I had to pull the plug and, sure enough, after rebooting one of the log files in /var/log contained garbage somewhere in the middle.

All this leads me to the conclusion that using sd-cards as a root filesystem should only be considered for test purposes. If you value your data:

  • Use a "good old spinning" harddisk (2.5" units are quiet and don't require much power). In the light of plug power supplies dying when powering external USB hard drives, make sure you got a separate power supply for the disk. This is also true for SSDs
  • Use a good-quality SSD disk with a proper wear-leveling algorithm and, preferably, SLC flash
  • Find an sd-card vendor that explains their wear-leveling algorithms in such detail that you can be sure wear-leveling is across the whole sd-card and somewhat smart.

BTW, there appears to be a wear-leveling algorithm designed for sd-card controllers that might solve most issues for good -- http://www.cis.nctu.edu.tw/~lpchang/papers/sac2007_ppt.pdf -- but I have yet to find out which sd-cards use this alrogithm...

66  Hardware and U-Boot firmware / Hardware / Re: Is my sheevaplug dead ??? on: February 11, 2010, 03:30:48 PM
You can use the SheevaPlug Installer to reflash the box via the JTAG interface, even when the flash is completely screwed up. See http://plugcomputer.org/plugwiki/index.php/SheevaPlug_Installer for details.

BTW, the instructions in the README.txt are a bit outdated; following the instructions in the Wiki (which are simpler) should work. Most importantly, the "installer" directory in the tarball downloaded from the page seems to be complete while README.txt seems to imply you have to copy bits and pieces into it. I believe I did not modify anything in it but can't quite recall now.

Furthermore, I did not have to follow the "important notes for newer plugs" despite the fact I just got mine a few weeks ago. The only thing I did was inserting the MAC address as described in README.txt.
67  Hardware and U-Boot firmware / U-Boot stuff / Re: Downgrade ext3 to ext2 on: February 11, 2010, 03:17:27 PM
I understood the instructions in the link you provided as a method to convert a root file system, not the root directory. The problem with the root file system is that you can't run tune2fs while it's mounted so you have to boot from a CD, or use an initramfs if it contains the required tools. Might be wrong, though -- I only glanced at the page for a few seconds.
68  Hardware and U-Boot firmware / Hardware / Re: Dead SD Card after 3 weeks : caused by Sheevaplug or something else? on: February 03, 2010, 07:21:24 PM
I've  been wondering about the reliability of SD cards in the last few months and there seem to be some issues that are worth mentioning:

  • There's a bug in the Linux MMC driver that will cause the card to be virtually "ejected" during suspend/hibernate operations and, upon resume, mounted again. Sometimes, it ends up with a different /dev name because the old name is still in use by a filesystem. When the filesystem finally wants to write the superblock (#0), the partition table is no longer there and for whatever reason, the superblock ends up in the MBR. Restoring the MBR fixes this issue until the next suspend... Probably not your issue, though
  • SD cards are mostly MLC flash RAMs with a lifetime of around 10,000 write cycles per cell (unless you got a SLC card which would live for around 100,000 write cycles per cell). Without wear-leveling, this is nothing and you could wreck an SD card in a few minutes. While most SD cards have some sort of wear leveling, some controllers seem to base their algorithms on free blocks which, lacking a command to declare a block to be free (in the past), is based on looking at the FAT. Of course, this doesn't work when formatting the card with anything but a FAT filesystem...
  • If wear-leveling is based on free blocks and using a non-FAT filesystem, wear leveling will effectively stop after the filesystem has written to all blocks at least once -- even if there's free space, the controller has no way to find out.
  • More recent/better SD card controllers seem to also consider copying "used" blocks around but it's hard to tell which kind of controller is in which card. It might be possible to detect this by the reduction in write speed once each sector has been written at least once but I never tried this. Sandisk, BTW, are somewhat open about the wear-leveling used on their cards and one might be able to get this kind of information when asking them.

When using SD cards under Linux, it seems to be a good idea to use ext2 vs. ext3 because ext3 causes even more writes for the journal. You should also consider using the deadline elevator for SD cards, telling it to focus on reads while collecting write requests in the cache for some time. I'm using the following script in /etc/rc.local to get this done when booting:

for i in /sys/block/mmcblk*/queue; do
  echo deadline >$i/scheduler
  echo 5000 >$i/iosched/write_expire
  echo 500 >$i/iosched/read_expire
  echo 1 >$i/iosched/fifo_batch
  echo 4 >$i/iosched/writes_starved

BTW, I'm using the SD card only for /boot and /var/log to reduce harddisk spinups; the rests of the system is on a USB harddisk (actually, it should be eSATA but this is not yet working with the enclosure I got). I currently have a 2GB SD card from Sandisk (cheap). Let's see how long it lasts

69  Hardware and U-Boot firmware / Hardware / Re: Enabling Esata on V1.3 Sheeva Plug - Progress Report. on: February 03, 2010, 06:39:14 PM
Hi all,

just to complete the story around external SATA enclosures: I got an eSATA SheevaPlug from NewIT and an eSATA 2.5" enclosure from Akasa with a 250GB Seagate drive. I installed Debian Squeeze, using an SD card for /boot and the enclosure connected as a USB drive. After patching sheevaplug-setup.c to turn on the SATA chip and recompiling the kernel, I tried to hook up the enclosure via eSATA but this failed with errors around bringing up the link. The eSATA connection as such is detected when I plug in the drive; furthermore, rmmod sata_sv stops the drive LED blinking and modprobe sata_sv starts the drive LED blinking again, accompanied by the errors messages about not being able to bring up the link. Thus, the cable as such seems to connected in one way or another...

Looking on the web for information about the enclosure, I stumbled across the following link:


While the spec sheet for the 1611 chip seems to indicate that Initio has finally arrived in the SATA II world, the problems when connecting Initio chips to the Sheevaplug seem to be the same as those reported by superpat. Like the 1610 chip, it doesn't seem to have a bypass for eSATA, thus is involved in all aspects of the SATA protocol. I assume the enclosure will work just fine when connecting it to a regular PC but I never tested it.

It looks as if there's an issue with the sata_mv driver and Initio chips. The Initio chips may be crappy but since they seem to work with regular PCs, it would be interesting to see whether there's something in the sata_mv driver which causes the problems.

Any takers?

Pages: 1 ... 3 4 [5]