I'm not all that keen to buy a USB hard disk, but I'm aware that SD cards aren't suitable for many repetitions of reading and writing.

Are there any steps I can take to extend the life of my SD card while it's being used by my Raspberry Pi?

Highly Irregular
  • 5,729
  • 10
  • 32
  • 40
  • 24
    If you write to it at full speed the whole time day and night 24/7- a 16gb will last about 30days. At normal usuage you can expect about 27 years based on 10,000 write cycles. If it uses 100,000 write cycles over 50 years. The bigger the card the longer it will last thanks to clever wear levelling logic – Piotr Kula Mar 15 '13 at 08:22
  • Wow that's great to know, I had no idea about your first point of 16gb sd lasting 30 days with writing full speed. I suppose constantly recording video to the sd and then transferring it isn't the best idea. – SSH This Jun 28 '13 at 16:10
  • 4
    With all the performance hits you'll take from these solutions, why not just pay $10 every few years? – Alexander Mar 02 '14 at 16:59
  • 1
    @PiotrKula I regularly read this "SD card wear is a myth" myth but fact is I'm going through "SanDisk Extreme PLUS" cards at a rate of about 1 card per 6 months in my Raspberry Pi running Home Assistant. – AndreKR Dec 07 '22 at 19:26
  • 1
    Yes... I think there is more going on in the PC usage of SD cards than it was intended for its use. The problem with HA specifically is going to be the number of micro transactions it does to log time series data. I think the problem is when you write a very small block of bytes it rewrites a whole sector/cluster on the card. These logs happen every second for each device you have registered.. I would strongly recommend getting a cheap SATA drive instead. that's what I've done with a massive success. No more failing SD cards – Piotr Kula Dec 07 '22 at 21:25

14 Answers14


These methods should increase the lifespan of the SD card by minimising the number of read/writes in various ways:

Disable Swap

Swapping is the process of using part of the SD card as volatile memory. This will increase the amount of RAM available, but it will result in a high number of read/writes. It is unlikely to increase performance significantly.

Disable swap with the swapoff command:

sudo swapoff --all

You must also prevent it from coming back after a reboot:

  • For Raspbian which uses dphys-swapfile to manage a swap file (instead of a "normal" swap partition) you can simply sudo apt-get remove dphys-swapfile to remove it permanently. Best to remove because setting the CONF_SWAPSIZE to 0, as explained in this answer, doesn't seem to work and still creates a 100MB swap file after reboot.
  • For other distributions that use a swap partition instead of a swap file, remove the appropriate line from /etc/fstab

Disabling Journaling on the Filesystem

Using a journaling filesystem such as ext3 or ext4 WITHOUT a journal is an option to decrease read/writes. The obvious drawback of using a filesystem with journaling disabled is data loss as a result of an ungraceful dismount (i.e. post power failure, kernel lockup, etc.).

You can disable journaling on ext3 by mounting it as ext2.

You can disable journaling on ext4 on an unmounted drive like this:

tune4fs -O ^has_journal /dev/sdaX
e4fsck –f /dev/sdaX
sudo reboot

The noatime Mount Flag

Assign the noatime mount flag to partitions residing on the SD card by adding it to the options section of the partition in /etc/fstab.

Reading accesses to the file system will no longer result in an update to the atime information associated with the file. The importance of the noatime setting is that it eliminates the need by the system to make writes to the file system for files which are simply being read. Since writes can be somewhat expensive as mentioned in previous section, this can result in measurable performance gains. Note that the write time information to a file will continue to be updated anytime the file is written to with this option enabled.

Directories in RAM

Highly used directories such as /var/tmp/ and possibly /var/log can be relocated to RAM in /etc/fstab like this:

tmpfs /var/tmp tmpfs nodev,nosuid,size=50M 0 0

This will allow /var/tmp to use 50MB of RAM as disk space. The only issue with doing this is that any drives mounted in RAM will not persist past a reboot. Thus if you mount /var/log and your system encounters an error that causes it to reboot, you will not be able to find out why.

Directories in external Hard Disk

You can also mount some directories on a persistent USB hard disk. More details of this can be found in this question.

The Raspberry Pi can also boot it's root partition from an external drive. This could be via USB or Ethernet and means that the SD card will only be used to delegate to different device during boot. This requires a bit of kernel hacking to accomplish, as I don't think the default kernel supports USB storage. You can find more information at this question, or this external blog post.

  • 22,458
  • 11
  • 89
  • 139
  • 19
    `noatime` should be a default. – Alex Chamberlain Jun 13 '12 at 08:54
  • 3
    @AlexChamberlain: `noatime` is not default, at least on Arch. – Jivings Jun 18 '12 at 11:19
  • 26
    It is in the latest Raspian builds. – Oli Aug 23 '12 at 23:06
  • @Jivings what's happen when disabling swap and get full RAM region reserved to process(with dynamic allocation for example) will the program crash???? – bouqbouq Aug 15 '14 at 22:23
  • @Makouda I don't know. I think you should ask a new question. – Jivings Aug 16 '14 at 07:16
  • In Ubuntu (which I use for manipulating & backing up file systems on unmounted RPi SD-cards), you can disable journaling with just `tune2fs -O ^has_journal /dev/sdXN`. Note 2, not 4 (from [here](http://askubuntu.com/questions/573957/disabling-journaling-in-ubuntu-14-04)) – RolfBly Jul 16 '15 at 20:30
  • 6
    According to this: http://superuser.com/a/168126/105936 it is not such a great idea to put `/var/tmp` to memory. Maybe you confused it with `/tmp`. – inf3rno Feb 13 '16 at 02:06
  • @Jivings: shouldn't that read "tune2fs" and not "tune4fs" ? – Cedric Martin Feb 28 '16 at 04:35
  • @CedricMartin I think `tune4fs` is the filesystem modification utility for `ext4`. But it seems synonymous with `tune2fs`. You can probably use either. – Jivings Feb 28 '16 at 15:59
  • 2
    Note that if `noatime` causes you problems, you can also use `relatime` which significantly reduces disk writes on read rather than removing them entirely. – Mark Booth Jul 13 '16 at 13:06
  • I would complement this with DISABLE Journalling on /, like this: `# echo u > /proc/sysrq-trigger # echo s > /proc/sysrq-trigger # tune2fs -O ^has_journal /dev/mmcblk0p2 # e2fsck -fy /dev/mmcblk0p2 # echo s > /proc/sysrq-trigger # echo b > /proc/sysrq-trigger` as explained on [waal70blog](https://waal70blog.wordpress.com/2017/12/16/disable-journaling-on-sd-card-raspberry-pi/) – ExploWare May 13 '20 at 09:02
  • @ExploWare "Disabling Journaling" is the second part of my answer already – Jivings May 13 '20 at 09:26
  • @Jivings The exact phrase you use is "You can disable journaling on ext4 on an unmounted drive like this" and I wanted to add a comment on how to handle MOUNTED drives. As this is often the case in a RaspberryPi sdcard (often one boot-partition and one root-partition) – ExploWare May 14 '20 at 10:17
  • @ExploWare Yikes, that doesn't sound like a great idea and I woudldn't recommend it. The unmount step means the journal data is flushed. If you disable journaling on a fs that is mounted then I imagine you'll lose the whole journal and any data not committed will be gone, but I'm not going to try it and find out. – Jivings May 18 '20 at 02:07
  • @Jivings it is actually unmounting the filesystem neatly, although using SytemRequests, (SysRq+U for example is unmount all and remount read-only) https://en.m.wikipedia.org/wiki/Magic_SysRq_key – ExploWare May 19 '20 at 14:30

If the options provided by Jivings aren't possible for your application then another option to extend it's life substantially is to use an SD card which is much bigger than you need.

Leave plenty of free space

Most decent SD cards use wear levelling algorithms to minimise the number of times each block is written, so if the SD card is bigger than you need the wear can be spread over a much larger area of free space.

Part of the reason wear levelling is so important is that some file systems, such as FAT (the default format for many SD cards), hammer the same sectors over and over again.

For more information on this, see the answers to the question Is it true that a SD/MMC Card does wear levelling with its own controller? over on Electronics Stack Exchange, especially this answer.

One interesting statistic from this answer is that

taking a 2GB card and writing it beginning to end over and over again averages about 10TB before the card is dead and no longer is writable.

But the worrying thing is that

SD cards will not let you know when data is bad, i.e. wont return an I/O error like a PC harddrive will.

This may make your choice of file system important if you need to guarantee reliable storage.

One final note: Doubling the size of the SD card could more than double the longevity of it.

I.e. if you have a 2 GB SD card with 200 MB free then switching to a 4 GB card will give you 11 times the free space, wear levelling capacity and thus longevity, while switching to a 16 GB card will give you 71 times the free space.

Mark Booth
  • 4,330
  • 2
  • 29
  • 42
  • 1
    To allow the SD card to perform wear levelling in the first place it needs to be told which blocks are actually free to use for that. [fstrim](http://man7.org/linux/man-pages/man8/fstrim.8.html) could help in doing so. – JimmyB Aug 27 '13 at 15:23
  • Trim isn't required, but without it a block is only reused when the OS reuses a block rather than when it stops using it. As far as I know trim is an SSD function and isn't supported by SD cards which are accessed by a much simpler protocol. – Mark Booth Aug 27 '13 at 16:07
  • @Mark, your first point is exactly right. - As to your second point, there's the (optional) `MMC_ERASE` command defined somewhere in the MMC/SD standard for just this purpose. Although of all the SD-Cards I've tried only one (-the one that came with my Pi-) actually supports it. – JimmyB May 26 '14 at 08:30
  • Does the partition size matter in this case? I mean, if I have a 16GB card and a system with an unique ext4 partition of 4GB, will it also leverage the remaining 12GB for wear leveling? – natenho Sep 22 '15 at 14:26
  • It's difficult to tell @natenho yes for an SD card with good wear levelling, no for one with a poor (or no) implementation. – Mark Booth Sep 23 '15 at 08:25
  • I think it is good to know, that it does not raise io error, so it is not as reliable as an SSD or HDD. It is better to backup data to a HDD frequently for example if you run a database from SD card. – inf3rno Feb 13 '16 at 02:12
  • "like a PC harddrive will". A HD only returns a write error if it can't seek to the starting block. The HD write can't verify that the data is correctly recorded on the magnetic surface. A subsequent HD read is required to verify EDAC. – Chad Farmer Jan 17 '19 at 19:07
  • Do you have a reference for that @ChadFarmer ? It sounds to me like you are referring to *seek* errors rather than *write* errors. Admittedly hard drives only normally do Read after Write verification when they reallocate a block, but many also turn on this feature when they detect an increased likelihood of writes failing (such as when temperatures are high). – Mark Booth Jan 18 '19 at 12:31
  • @Mark, sorry, no references (just a comment). Writes just expose the magnetic surface to a magnetic signal. The write operation does not have way to determine if the media responded correctly to the magnetic signal.
    You are correct that write-verify exists, but it adds a full rotation waiting for the block to come back around to be read. As a result it is only used in special circumstances (correct me if I'm wrong). A drive's proprietary firmware can do unusual things, but latency is still visible.
    – Chad Farmer Jan 21 '19 at 17:05

The only thing I see is to NOT swap on the SD card.

Swapping on the Sd card is probably what could kill your SD card.

If you need more RAM, you can try to use zram, theres a post on http://raspberry.pi.gw.gd/t50-Using-ZRAM.html giving some details about using ZRAM on the raspberry pi

More info for zram on http://en.wikipedia.org/wiki/ZRam

Also the most recent SD cards are know to be much more solid than older ones, buying a brand new class 10 SD card is probably a good option is you want to see it last a long time.

  • 380
  • 2
  • 6

Most people here talk about their assumptions and not fom personal experience.

I have been using my RaspberryPi with RasPBX as a company switchboard with 8 extensions and a fax. We have 3 ip based trunks and one landline through LinkSYS SPA3000. It took only 1 month for my initial Kingston 4 GB SDCard to bite the dust.

I was still experimenting and did not have a backup. BTW the Pi is connected to an APC UPS. I then re-setup the entire RasPBX from the scratch, but this time I moved /var/log and /var/lib/mysql to our corporate NAS. This SD was Still OK after 3 months.

Then we had a very hot summer. During the third month the pi started not to detect the ethernet out of the blue. Then one day I found it all Leds are dim and it would not boot.

I've replaced the Pi with a fresh out of the box working one. The out of order one started to work after cooling down but it works rather erratic and when it boots to RasPBX the video mode won't switch to graphics, it stays in 80*25 Text. It was really messed up. I've ordered a heatsink set since. The new Pi works with it now for more than 2 months 7/24.

So if you will use the pi in a 7/24 environment, don't be cheap - buy heatsink and avoid using /var/log and other busy directories over the SD CARD.

  • 2,919
  • 3
  • 25
  • 34
Kerem Ersoy
  • 197
  • 1
  • 5
  • Making sure var/log is on a suitable device sounds like excellent advice. Out of interest, in that initial problematic month, were you storing voicemail boxes on the USD card too? I'm just wondering if high endurance uSD cards like the ones designed for Dash Cam use might be better for my RasPBX deployment if I decide to enable voicemail boxes. – Mark Booth Jan 28 '19 at 16:00

You could try running Puppy Linux which is completely ram-resident. It's very small and blindingly fast since it runs completely in memory by copying the storage image (on SD card in your case) into RAM at boot and then flushing changes periodically back to storage. The frequency of this save is user controlled including manually.

Puppy uses the layered aufs or older unionfs filesystem with any of the standard Linux filesystems like ext3 or ext4. It can also reside on FAT, or NTFS partitions.

There are at least a couple of versions of Puppy specifically designed for the RPi, one of them created by the "Puppy Master", Barry Kauler.

For more, go to http://wikka.puppylinux.com/Puppi

  • 261
  • 2
  • 5

I have compared all solutions the utilitze TMPFS and the best answer is a synthesis of the script prepare-dirs (see http://grenzdebiel.dyndns.org/wordpress/?p=98) with a proper /etc/defaults/tmpfs ((see http://www.a-netz.de/2013/02/ramdisks-for-the-raspberry/).

The necessary steps to perform on raspbian are:

1. edit /etc/default/tmpfs and set:


I'd recommend the following sizes:


2. enable additional directories using /etc/fstab

tmpfs   /var/log                tmpfs   size=20M,defaults,noatime,mode=0755 0 0 
tmpfs   /var/cache/apt/archives tmpfs   size=100M,defaults,noexec,nosuid,nodev,mode=0755 0 0
tmpfs   /var/spool/cups         tmpfs   size=100M,defaults,noatime,mode=0755 0 0
tmpfs   /var/spool/cups/tmp     tmpfs   defaults,noatime,mode=0755 0 0

3. use the script /etc/init.d/prepare-dirs to create missing directories in /var/log so that all daemons start

See at the end what it contains in my case.

4. Make the script executable chmod 755 /etc/initd/prepare-dirs.

5. Make sure that the script will be started first on boot before your daemons start: update-rc.d prepare-dirs defaults 01 99

contents of /etc/init.d/prepare-dir:

# Provides:          prepare-dirs
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Required-Start:
# Required-Stop:
# Short-Description: Create needed directories on /var/log/ for tmpfs at startup
# Description:       Create needed directories on /var/log/ for tmpfs at startup
# needed Dirs
case "${1:-''}" in
        typeset -i i=0 max=${#DIR[*]}
        while (( i < max ))
                mkdir  ${DIR[$i]}
                chmod 755 ${DIR[$i]}
        # set rights
        chown www-data.www-data ${DIR[0]}
   echo "Usage: $SELF start"
   exit 1

That's it.

  • 103
  • 2
  • 141
  • 1
  • 3

These are my recommendations for a Debian 8.0 (Jessie)

They are based on iotop -bktoqqq and iostat -dzp 5. You should run these commands first to get an idea of the problem and its solution.

1. Disable swap

sudo systemctl disable dphys-swapfile
sudo rm /var/swap

2. Use mount options and RAM

Mount all partitions on the SD card with the noatime,commit=1800 options and mount the following directories to RAM with these entries in your /etc/fstab file:

/dev/mmcblk0p1  /boot           vfat    defaults,noatime,commit=1800  0       2
/dev/mmcblk0p2  /               ext4    defaults,noatime,commit=1800  0       1

tmpfs           /tmp            tmpfs   size=50M,nodev,nosuid     0       0
tmpfs           /var/tmp        tmpfs   size=10M,nodev,nosuid     0       0
tmpfs           /var/cache/samba tmpfs   size=5M,nodev,nosuid     0       0

Commit will delay the writes and collect them first.

3. Log the most frequent log files to /var/tmp/log/

See my description How can I reduce the writing to log files.

4. Stop Chromium from hammering the SD card

As it turns out Chromium writes heavily and cannot be stopped (see 176727, 52663). This effects the cache and the user data directory. The Chromium/Tips and tricks explain how this can be moved to RAM. Since the Raspberry doesn't have much RAM the suggested Tab Suspender is useful for saving RAM.

a) Cache

Limit the cache size and move it to RAM by editing /etc/chromium-browser/customizations/00-rpi-vars to

CHROMIUM_FLAGS="--disable-quic --enable-fast-unload --enable-tcp-fast-open --disk-cache-size=10000000 --media-cache-size=5000000"

Now the cache is small enough to be moved to the RAM disk by changing the XDG_CACHE_HOME entry in /etc/security/pam_env.conf to


Now my two users have a small browser cache in RAM. If that's not sufficient for you change the cache or /tmp/ size as necessary.

b) User data dir

Also the user data dir (.config/chromium/) experiences heavy writes. The Profile-sync-daemon is recommended by the Chromium/Tips and tricks. It was developed to manage your browser's profile in tmpfs and to periodically sync it back to your physical disc. Unfortunately the package is not yet part of the Raspbian 8.0 (Jessie) distribution. So I have not tested this yet.

5. Free space on the SD card

Free space by uninstalling packages and files you don't need. This should spread the wearing more evenly across your partitions.


Now run iotop -bktoqqq and iostat -dzp 5 again and see a significant reduction in the write access when the system is idle. Nothing gets written to my disk for many minutes. And don't worry about the green ACT LED flashing. Apparently it is not a good write access indicator.

  • 113
  • 1
  • 5
Frank Breitling
  • 967
  • 1
  • 14
  • 28
  • Just want to add that "freeing space to spread the wearing more evenly" could also mean expanding your filesystem if your installation image does not take up all of your SD card space. Additonally, because more space spreads the wearing and extends the card's life, a "bigger" card should last longer. – GChuf Jul 07 '20 at 12:09

Disable Swapfile:

sudo dphys-swapfile swapoff

There is no necessity to uninstall, however if you are not using it, and do want the space, you can safely remove it. Alternate command to remove:

sudo dphys-swapfile uninstall

Usage: /sbin/dphys-swapfile {setup|swapon|swapoff|uninstall}


Flash Cell Endurance:

  • For Multi-Level Cell (MLC) Flash, up to 10,000 write cycles per physical sector.
  • For Single-Level Cell (SLC) Flash, up to 100,000 write cycles per physical sector.
  • Newer SSD offer 1 million write cycles per physical sector.

It is purely mathematical on large cards and normal wear. If you were to write to a 8GB MLC type flash card day and night over and over it would take about 30 days to kill it.

Episode 99 at Techsnap talks about wearing out SSD's and Allen explains how it is impossible to wear out a SSD in everyday usage and we do not need to worry about disabling swap, crons and all that. It just works now! The smart wear levelling takes care of everything.

Normal wear as quoted per Kingston should give you 27 years of life for the life in a professionals digital camera.

Which for normal DSLR cameras you might fill it up once every few months.. depends how much you travel. Taking into consideration a Pi, if you experiment allot and re flash often then it may take more of a toll. Usually once you are happy with a distro... you don't re flash it for months or years. So to prolong SD wear it would be good to follow some advice on reducing IO on the SD.

The price of flash has fallen and the technology is a lot better.

Most SD cards will outlive two or three generations of devices and by that time it will be considered to small and too slow to use with a much better and cheaper upgrade available!

Piotr Kula
  • 17,247
  • 6
  • 64
  • 104
  • A Raspberry Pi set up with a webcam for security purposes may well be writing data 24/7. I guess in that case a SSD is probably better. – Highly Irregular Mar 15 '13 at 08:46
  • 1
    Yes but it is not writing ALL the sectors the WHOLE time sequentially. It is managed for least wear and new data always goes to the least accesses sector/area. The video wont overwrite the file system files or paging files. Besised how many hours can you get on a 16GB flash drive? Usually CCTV should be accessible 15-30days later! Use a 1 TB drive instead or NAS to store for historical purposes. Even short term for storage and transfer you will get years out of a SD card! Better yet use a 32gb SD but cap the folder to 16GB- You will more than double the life time usign that technique! – Piotr Kula Mar 15 '13 at 10:10
  • 4
    @ppumkin, can you please tell us how you actually use your SD cards in your RPi(s)? Lots of us (Google "raspberry damaged sd") have encountered fatal failures (me more than one, incl. Kingston, now that you mention) with their default Raspbian setups, despite the impressive vendor numbers... It may be RPi, not SD, but your paper figures are still unsubstantiated without any references to the (should I say well known?) RPi SD issues, your own actual field practices, or, better yet: case studies experimentally debunking the SD damage "rumors". – Sz. Oct 21 '14 at 11:27
  • 1
    Look, everything I talk about is linked to reference. OK, you want to know how I use it? I do not! Because the Pi, is really a big pain in the ass! SD cards keep failing in it, and its not the SD card fault. Either the Pi hardware or software is bricking these things. I think it is the unstable voltages provided by cheap USB power supplies. The new B+ has regulators on them . Thank god! This fixed WiFi, sound feedback and I pray to god bricking SD cards. I still need order some but im playing with Netduino now, no SD crashed on that yet. – Piotr Kula Oct 22 '14 at 12:15
  • I don't believe 10,000 write cycles at all. See also: [how to damage a flash storage device](http://goo.gl/xpkxNG) and some good [flash memory](https://goo.gl/Alw8jb) theory. I've had 2 SD cards broken from frequent small updates to a small file. Symptom: can't update the file anymore. Can read it (Salvage time!). Subsequently, Pi will not boot anymore, Journal broken (connect a monitor). So I think the damage is caused by frequent updates to Linux' admin, not to the file itself. So I think Jivings answer has good ideas. – RolfBly May 28 '15 at 20:55
  • What make of SD card do you have? I bought genuine class 10 Kingston 8GB, I basically reflashed them about 50 times, updated them twice as much. Compiled Mono on them about 5 times... still going well.. If you have some eBay job cards (with Kingston sticker) but old MMC flash in them... they wont last.... I had those too. 3 OS flashes and they died! – Piotr Kula May 29 '15 at 07:05
  • 1
    @ppumkin I used SanDisk. Not ebay ones. There is a big difference between reflashing an SD card (for reuse in a camera, say) and using it as the home of an operating system. You should be more specific as to how exactly _you_ use yours, and how long they lasted. No need for me to repeat Lunakids comment, but I fully agree with him or her. . – RolfBly May 29 '15 at 18:27
  • OK - I see the confusion with the camera bit.... edited – Piotr Kula May 29 '15 at 19:37

As mentioned before, the main issue are files and directories which are not worth being saved between reboots, but get written quite often, i.e. cache files, download folders, etc.

Raspbian as well as Debian and Ubuntu have a package called unburden-home-dir whose primary purpose is to symlink such files to a less problematic place like e.g. a tmpfs mount or an external harddisk which is less prone to wearing off.

It's commonly run at login time under X and targetted towards GUI application's cache files, but can also called from scripts or such and configured for arbitrary files in a user's home directory.

Axel Beckert
  • 1,122
  • 11
  • 26

Just a tiny reduction of write cycles can be reached by streaming the syslog output to another server. Of course, having such a server with a syslogd running is a precondition. However, with the Pi being a toy for Linux enthusiasts this is probably very often the case. :-)

To activate this streaming simply insert a statement like

*.*    @myserver.mydomain

at pretty much the top of the of the file /etc/rsyslog.conf, comment out all the other lines, and restart the logging by issuing service rsyslog restart. After this the messages should be coming in on the selected server.

One clear advantageous side effect of this is that you can easily monitor your Pi in conjunction with other machines on the same server. One downside is that during system startup and shutdown you may loose some messages when the network connection has not been established yet or has already been shut down.

  • Note that modern Linux systems (including CentOS 7 and Debian 8, and systems based on those such as Raspbian 8) do all logging to `journald` which stores them in the systemd journal. They also configure `journald` to forward the logs to the syslog socket on which `rsyslogd` is listening; that places additional copies of the messages in the log files under `/var/log`. If you're comfortable using `journalctl` to browse your logs (and it works much better than `/var/log` once you're familiar with it) you can completely disable `rsyslog` and save some writes. – cjs Apr 06 '17 at 16:29

Note: The 100,000 cycles limit is a hypothesis that applies to every computing device, even the keys in a keyboard.I believe running Pi in proper cooling conditions and proper shutdown/start cycles will give your better results rather than going into analogies.

Also this may augment my above opinion.

Add a new user in addition to user Pi[default]. Point the home directory of the new user in external drive[thumb/hard drive]. Give the new user, super-user permissions and start using it as your primary account.

I hope this helps..

  • 227
  • 1
  • 5
  • I always try to type less to save on keyboards ;) – Piotr Kula Nov 05 '13 at 15:38
  • Adding a new user won't prevent busy `/var/log` and `/var/tmp`. Also, __having evidence from experience__ that proper cooling makes a difference is much better than saying "I believe". – RolfBly May 29 '15 at 05:28

Use busybox' syslog daemon (in the package busybox-syslogd on Raspbian/Debian/Ubuntu) instead of the default syslog daemon (usually rsyslog). By default on Raspbian/Debian/Ubuntu, the syslogd of busybox only logs into ring buffer in memory and not onto disk. The ring buffer has a size of 128kB by default, i.e. old log entries rotate out rather soon and are gone then. But you can configure it to use more RAM for it.

Nevertheless this is a far better solution than not having a syslog daemon at all, i.e. you can still log in and read the log entries of the approx. past few hours or days (depending on the configured size of the ring buffer) with the command logread. You can also use logread -f to get a tail -f like behaviour to e.g. only store interesting log entries using a filter script or to forward log entries over the network elsewhere, e.g. using stunnel or such.

Axel Beckert
  • 1,122
  • 11
  • 26

Couple of things I did:

chmod of the dphys-swapfile (somewhere in /etc - not near the PI at the moment) to:

sudo chmod a-x dphys-swapfile

I get minor errors on boot (can't start service dphys-swapfile) - Suppose there's a better way... rc-update??

Also, I capture images from the camera module, to eventually put on my webserver (the Pi). I formatted /dev/ram0 to ext2, mounted it as /media/ramdrive (using /etc/init.rc, I think). It's 4megs, big enough for one snap. No writes to SD.

The server (oululife.dnsdynamic.com) is experimental, but on the web. To really stress it out, I let it also stream an MP4 episode of 'Heartbeat*'. It runs lighttpd, Mysql, PHP, WordPress, and even when I remotely stream over the web it hardly breaks a sweat, load average about 0,2. No over-clocking at all. Model-B rev. 2, up 24/7. So, if I can get my logfiles into the other 15 /dev/ramX, I reckon my Micro-SD 16G card will last years....

  • 103
  • 4