Category Archives: ramlog

Thoughts on RAM

These are just thoughts – hopefully someone is going to write in and tell me I have it all wrong.

As regular readers will know I have reviewed (and messed with) MANY small Pi-type boards including the Raspberry Pi, Banana Pi, NanoPi etc etc.  I’ve also had a go with some power supplies and even made up my own solutions at board level. We’ve had discussions about the issues with FLASH and minimising writes and so mentally it all seems to be coming together. What is needed for our home control central control projects is:

A cheap SBC with enough RAM to be able to lose some for LOG2RAM and buffering for datbases etc to utterly minimise writes to FLASH – so ideally maybe once per day, stuff in RAM would be written to FLASH.

To go with the above then – clearly a power supply is needed that will not fail – i.e. with battery backup.

Sure, if you through enough money at this – there are solutions for everything but at a budget?

Firstly, RAM – just not enough – some of these boards have 256Meg and 512 Meg  - enough for normal use but if you start stealing some of it to run Log2RAM and RAM-buffering databases (RAMDISK) then you start to run out – it seems to be that 2GB of RAM would be a nice figure yet I’m only aware of a small number of these boards that have this much – if memory serves me well, the Odroid C2 – and a board I’ve only just recently heard of – the FriendlyArm NanoPi K2. There will be one or two others I’ve long since forgotten.  The Raspberry Pi people for example apparently have no intention of moving to 2GB in the near future. We see people using these boards for media management yet if you look at the notes from the designers of such software they usually suggest 2GB minimum RAM!  I don’t do media management but our chats about FLASH have me using Log2RAM and RAMDISK and depending on your needs you could be looking at losing 512Meg or your precious RAM.

Power supplies – especially important given the above - recent testing has shown that we don’t seem to have a single low cost unit available that can handle the battery going down to zero – and recovering gracefully while the the load is connected or having to press a button or some impractical manual interjection – and bearing in mind that several of the better boards need  2amps+.   Looking back through the blog there is not one – there’s one on Kickstarter but that is now way, way late in appearing and for all we know THAT might not do the job.

What are people’s thoughts – am I talking nonsense? Am I missing some products? What do you think? Do people have low-cost solutions I’m not aware of?


RAMLOG and the mysteries of Linux

ramJust as I thought I was getting to grips with this – reality comes back to punch me in the teeth…

I have 2 Raspberry Pis running Debian (latest 4.1 Linux version) and RAMLOG . In each case at 6.25 in the morning they restart RAMLOG (which for those who don’t know, ensures that all log files are updated in RAM to save wearing out the SD). A restart flushes all the logs to disk – and so it makes sense to do that daily (assuming you have some kind of un-interruptable on the PI which I do in the form of cheap USB battery/charging units.

At 6.25am, Pi number 2 sends me an email to say that Ramlog has restarted. Pi number 1 does not send me an email.

So – I went to WEBMIN this morning and looked at the CRON jobs – identical. In each case I pressed the SAVE AND RUN button – and in each case they both reported back that RAMLOG is restarting.. Lovely – except that NEITHER sent me an email.



The Raspberry Pi SD Wear Issue

Raspberry PiReading around the web it is easy to see that SD memory and lifespan are very poorly understood. There are conflicting explanations of lifespan, there are solutions which don’t work because someone didn’t actually test them before writing up … what a mess.

So here’s the deal. SD memory (the type you put in the PI to boot up) has limited write time – SO DOES USB MEMORY.

How long the microSD in your new Raspberry Pi2 will last is anyone’s guess and depends on “disk” activity, i.e. the number of WRITES (the number of READS is irrelevant).

So how to maximise this. It would seem that you CANNOT offload the whole thing to a hard drive.. but you can have the Pi boot up from the microSD – and then do everything ELSE on the hard drive. You cannot power the hard drive off the USB on the Pi as it does not provide enough juice – so you’d need a powered USB hub. This article looks good – I only got as far as transferring files externally so don’t ask me questions on it – but this seems to be one of the better explanations for using an external file storage.

Another way to improve the life of the SD and one that makes sense to me is a RAMDRIVE. That is instead of allowing the Pi to write constantly to log files on your Pi, have it read all log files into RAM at power up – write to the RAM and then on (intentional) power down, write back to the SD. RAM of course, you can write to forever without issue.

This kind of implies reliable power and I suggest you hunt out an uninterruptable supply – you can sometimes use those little phone charger supplies but I have found that some work, some don’t. The easy way, after backing up your Pi, is to try any one you have lying around. Plug power into the supply, plug the supply into the Pi. Watch the Pi on screen and test the keyboard or mouse. Repeatedly remove and reconnect the power to the supply – if the Pi works without any issue throughout this - then you’re probably onto a winner. I have 2 of them that work, 2 of them that don’t.

Ok, so there is a package called Ramlog which does the job of ensuring the logs are only written at power down. I followed two sets of instructions both of which failed part way through because the writer hadn’t actually tested what he was writing down, missing off a SUDO (super-user-do) command or similar. This explanation worked for me.

It would seem that SOME SD memory has something called “wear-levelling” in which the write use of blocks of memory in the chip are evened out so that continuously writing to one block ACTUALLY doesn’t happen as the wear is “spread” – sadly trying to find out how well this works and with which manufacturer’s chips it works – is something akin to dabbling in witchcraft. There is just so much rot out there so personally I’m not counting on it.

Oh and how do you tell if you’re reducing the number of writes – less or no flashing lights on your Pi.

I hope that helps. I’m coming to the conclusion that for long term use an external drive might be a good idea but I think I’ll wait a while until someone comes up with a package or batch file to make this nice and easy – meanwhile Ramlog seems like a good compromise.

About the only thing I did notice is that my SD usage according to WEBMIN before I installed Ramdisk was 3.5GB and after it was 7.10GFB but that’s clearly rubbish – it would be interesting to see it anyone else gets any “special effects”.