Notes from Sven Latham
I’m going to need to remember this, as it runs slightly counter-intuitive to what I was expecting (although makes sense).
Code compiled in App_Code is available globally, so any other piece of code can reference it.
Code compiled in code-behind (i.e. the .cs files ‘behind’ ASPX pages) is only available to its corresponding ASPX page unless you explicitly reference it.
This can be done by adding the following to the ASPX page:
<%@ Reference Page="......link to .aspx" %>
One to remember.
It’s been a little while since my last post about visitor tracking, and some updates are long overdue.
The good news is that it’s ready to launch, with lots of interest. This has been a challenging project in many respects, and I’ll be documenting the various aspects shortly.
Initial results are very promising. We’re seeing figures that have never before been seen; stats and information that were until now completely invisible. It’s thrown up issues, about data transfer, privacy and many other factors.
Privacy is a huge issue for me – there are lots of companies that (in my mind) are far too aggressive on this issue – so expect more on this as I continue to share my work.
It’s exciting stuff, and I’m keen to share my experiences and thoughts for others. Stay tuned!
As part of my visitor mapping project, the bulk of my time has been spent throwing curse words at the SD cards.
Raspberry Pis depend on SD cards. There’s little other choice. More specifically, the newer devices use Micro SD cards. It’s fairly incredible to realise just how much data can be stored on something around the size of a thumbnail, but I digress.
The problem with these cards (& flash memory in general) is that they’re very sensitive to corruption. Any power fluctuation or problem writing is a potential problem, with a real chance that the next boot will end in failure/disaster.
In my experience (ten devices in lab conditions; regular reboots) failure rate was as high as one in ten reboots. Slightly oddly, software resets (i.e. rebooting from the command line) appeared to fail more often than unpredictable power loss.
Read-Only is a winner
There is a way to boot a Raspberry Pi in read-only mode, although it requires a bit of care. I found a couple of ways to do this, by editing the boot config file and by setting the fstab to boot as read only.
The consequences are hopefully clear – nothing is retained. However, it’s also possible to temporarily remount the file system in writeable mode (and revert shortly after). My software is capable of self-updating, and writes its logs to the filesystem in case of Internet problems. Both work very well.
This website gave the best instructions. It includes removing a bunch of daemons that – frankly – I had no need for. I also removed fake-hwclock (for reasons which I’ll describe on another post) and preferred mounting ramfs on places like /var/log/ over linking.
The results have been pretty impressive. Since switching to this method I haven’t had a single corruption issue (despite many tens of reboots)
Power is a concern
I suspect that one of the big problems is power, and began testing with a voltmeter. My suspicion is that brownouts – i.e. dips in power – were causing reboots and corruption.
The latest Raspberry Pi hardware supports a configuration that boosts the current to USB drives. Setting max_usb_current=1 in /boot/config.txt appears to increase the per-device supply to 1.2A which avoids many of the power-related issues on high-demand peripherals.
My non-scientific and unmeasured experience confirms this. I’ve seen much better performance and reliability as a result, and – although can’t be sure – I suspect this has helped the SD card woes as well.
In any case – touch wood and all that – this appears to have solved the corruption issues.