Increasing flash memory lifespan

Hello.

I've been trying to setup a longlasting linux installation on one of the plug computers (SheevaPlug). Basically it's an embedded device with debian-based Linux ARM, which is booting from flash NAND memory chip. I would like to customize the setup a bit in order to extend the lifespan of the internal MTD and the device itself. The device is going to be running certain network services like samba/NAS (external USB HDD), SSH, FTP and the like. Generally I would want to have the device perform the least possible amount of writes to the internal flash to minimize memory degradation.

Any suggestions?
I came up with a few questions and ideas, but I am unsure what the best choices are.

• Add "noatime,errors=remount-ro" to all local filesystems in fstab.
• Which filesystem best to use? ext2, ext3, ext4, reiserfs, btrfs, jffs, fat, ubifs ???
• The apt package manager had a huge cache of files on my MTD - when I ran apt-get clean about 250MB of packages got cleaned from the 512MB NAND device. That's a lot! Perhaps I can somehow disable caching?
• Disable local logging. A lot of stuff gets written to /var/log. What to do about this? Redirect to external server?
• How many folders should I mount in tmpfs? /tmp, /var/run, /var/lock, /dev/shm, /dev/pts ???, /var/log, /var/tmp, /var/spool, /var/cache Can I mount entire /var folder on tmpfs???

Regards!

Hi,

You can look at;

Linux Kernel I/O schedulers; Completely Fair Queuing (CFQ) "is an I/O scheduler for the Linux kernel which was written in 2003 by Jens Axboe." Deadline "The goal of the Deadline scheduler is to guarantee a start service time for a request" Noop "The NOOP scheduler inserts all incoming I/O requests into a simple FIFO queue and implements request merging."

For your solid state devices the 'Noop' scheduler for each would be the best fit. Let your mechanical devices use the default 'CGQ' scheduler.

This how I setup my 'SSD' in '/etc/rc.d/rc.local';

#09-25-12 gws 20:07
#
#08-20-12 gws 14:38
#set minimum swappiness
#
echo 1 > /proc/sys/vm/swappiness

#08-20-12 gws
#sets scheduler for SSD to 'noop'
#SSD=(device ID's of all 'SSD': see note below)
#Note Information revised from ArchWiki;

#This provides the links listed with targets information to place in bash array
#'SSD= ( ) parentheses in below 'SSD= ( );

#ls -l /dev/disk/by-id
#lrwxrwxrwx 1 root root  9 Aug 19 11:27 ata-OCZ-AGILITY3_OCZ-C93VFN4X0532CVMP -> ../../sda

SSD=(ata-OCZ-AGILITY3_OCZ-C93VFN4X0532CVMP)

declare -i i=0
while [ "${SSD[$i]}" != "" ]; do
  NODE=`ls -l /dev/disk/by-id/${SSD[$i]} | awk '{ print $NF }' | sed -e 's/[/\.]//g'`
  echo noop > /sys/block/$NODE/queue/scheduler
  i=i+1
done

#08-20-12 gws 14:45
#get some additional gain by setting up a write-back cache
hdparm -W1 /dev/sda   #where x= a,b,c,d...

#
#09-20-12:16:14 gws bumblebee
#setup for video switch for Intel or Optimus
if [ -x /etc/rc.d/rc.bumblebeed ]; then
     /etc/rc.d/rc.bumblebeed start
fi

Hope this helps!

Thank you for the hint. It's not a real SSD I'm using, it's an internal NAND flash chip that is soldered onto the circuit board of my SheevaPlug.

Here's a fstab I came up with. It could use some improvements though. I'm not 100% certain about the use of parameters i.e. is noexec a good idea on /tmp? I read somewhere that certain programs will break/not run because of it.

# <file system> <mount point> <type> <options> <dump> <pass> proc /proc proc defaults 0 0 ubi0:rootfs / ubifs defaults,noatime,nodiratime,commit=600,errors=remount-ro 0 1 tmpfs /run tmpfs size=1M,rw,nodev,nosuid,noexec,mode=0755 0 0 tmpfs /run/lock tmpfs size=1M,rw,nodev,nosuid,noexec,mode=1777 tmpfs /tmp tmpfs noatime,nodev,nosuid,mode=1777 0 0 #noexec??? tmpfs /var/log tmpfs defaults,noatime,nodev,nosuid,noexec,mode=0755 0 0 tmpfs /run/shm tmpfs defaults,nodev,nosuid,noexec 0 0 tmpfs /var/cache/apt/archives tmpfs defaults,nodev,nosuid,noexec 0 0

Hi,

As root from terminal/console with device(s) installed do 'ls -l /dev/disk/by-id' then 'fdisk -l'. Look and see what you find.

You can select the scheduler for your device.

This is a flash on my system: usb-TOSHIBA_TransMemory_000AEBFFB4C45B88100001BB-0:0 -> ../../sdc

By doing;

cat /sys/block/sdc/queue/scheduler
noop deadline [cfq]

'cfg' is the assigned scheduler but I could then;

echo noop > /sys/block/sdc/queue/scheduler

I would then be using 'noop' scheduler for that device & filesystem. advantage of the 'noop' is it is a 'FIFO';

Noop "The NOOP scheduler inserts all incoming I/O requests into a simple FIFO queue and implements request merging."

You would not need the facilities of 'cfq' or 'deadline' for the memory card or a flash.

It's not a block device (i.e. /dev/sda), it's raw flash (/dev/mtd0)! And I'm running UBIFS ontop of it. Do these devices even use schedulers?

http://lists.infradead.org/pipermail...st/019236.html
http://lists.infradead.org/pipermail...st/019237.html


Anyway, I did some research on the fstab and file systems. It would seem that a UBIFS is indeed a good choice for a raw flash device. There were some changes made to my fstab. The ubifs does not support noatime parameter, so it was removed. There shouldn't be a need for a remount "ro" on errors because this is already done in UBIFS automatically by design. I also removed the commit line because it doesn't change much.

/var/run is symlinked to /run
/var/lock is symlinked to /run/lock
/dev/shm is symlinked to /run/shm

# <file system> <mount point> <type> <options> <dump> <pass> proc /proc proc defaults 0 0 /dev/ubi0_0 / ubifs defaults,bulk_read 0 1 tmpfs /run tmpfs rw,size=1M,nodev,nosuid,noexec,mode=0755 0 0 tmpfs /run/lock tmpfs rw,size=1M,nodev,nosuid,noexec,mode=1777 tmpfs /run/shm tmpfs defaults,nodev,nosuid,noexec 0 0 tmpfs /tmp tmpfs defaults,noatime,nodev,nosuid,noexec,mode=1777 0 0 tmpfs /var/log tmpfs defaults,nodev,nosuid,noexec,mode=0755 0 0

I'm currently trying to figure out whether it is sensible to include these mountpoints in tmpfs.

/var/cache
/var/mail
/var/spool

The apt-get is giving me some puke whenever I mount /var/cache (or /var/cache/apt) as tmpfs. Perhaps I should only mount /var/cache/apt/archives? But the apt folder is definitely going to have to be mounted, because apt stores all downloaded packages in here - this can consume a lot of space when you're not 'apt-get clean'-ning your system after installing stuff. not to mention useless flash writes.

Hi,

I was thinking that 'UBIFS' used a 'FTL(File Translation Layer)' therefore was a 'mtdblock' device. After clearing things up for myself, it turns out that a raw device would be degraded using a 'FTL' technique with 'UBI'. Sorry!

Update: Changed fstab a bit. I'm becoming content with my setup.

# <file system> <mount point> <type> <options> <dump> <pass> proc /proc proc defaults 0 0 /dev/ubi0_0 / ubifs defaults,bulk_read 0 0 tmpfs /run tmpfs rw,size=1M,nodev,nosuid,noexec,mode=0755 0 0 tmpfs /run/lock tmpfs rw,size=1M,nodev,nosuid,noexec,mode=1777 0 0 tmpfs /run/shm tmpfs defaults,nodev,nosuid,noexec 0 0 tmpfs /tmp tmpfs defaults,noatime,nodev,nosuid,noexec,mode=1777 0 0 tmpfs /var/log tmpfs defaults,nodev,nosuid,noexec,mode=1777 0 0 tmpfs /var/cache/apt tmpfs defaults,nodev,nosuid,noexec 0 0

I could swear that apt moaned about not finding certain stuff inside /var/cache/apt last time I used it, but after reinstall it seems to work. I replaced the fsck flag from 1 to 0 on the rootfs. Having a 1 there causes fsck to run on boot and fail because fsck.ubifs doesn't exist. I disabled .bash_history and nano history.

Also: Here is a nice tutorial on installing Debian. This is what I used to install wheezy onto UBIFS.
http://www.blaicher.com/2012/07/inst...ug-into-flash/

EDIT: Running /tmp with noexec options requires this: http://blog.netflowdevelopments.com/...-with-apt-get/

EDIT2: Changed permissions of /var/log to 1777 as some services complain they have no write access to this folder. Also, should you be running nginx, a folder /var/log/nginx has to be created before nginx starts. Else it will complain that it cannot open log files and exit. the script /etc/init.d/nginx should be edited to create the folder automatically.