Reduce write to SD cards

i am not sure what you mean with "Snappy phone" there has been no attempt yet to use phones on snappy and there will likely not be any until the phone base has properly moved to 16.04 first (which is probably still half a year away or so, phones still massively depend on upstart while snappy has systemd as hard requirement, this is a lot of work)

i highly doubt you will be able to wear out a modern SD with the current snappy base install within several years, there are no processes that do any massive write operations (perhaps beyond some syslog logging that you could disable), we do not use any swapping or any other write intensive operations by default in snappy images ...

to my knowledge there is no specific technology on phones to prevent excessive writes beyond a careful selection of packages and defaults (which applies in the same way to snappy images)

i personally havent managed to wear out a single SD since i started working on snappy two years ago, not even the cards i use for deaily re-flashing and testing, is there any evidence that this happens ?

the only way i could imagine to wear out an SD on a snappy install currently would be an application or service snap that does constant excessive write operations for persistent data it needs. for this use-case there wont be any solution though if the data really needs to be persistent.

> the only way i could imagine to wear out an SD on a snappy install currently would be an application or service snap that does constant excessive write operations for persistent data it needs. for this use-case there wont be any solution though if the data really needs to be persistent.

Agreed, for such a use-case I suggest splitting the writable partition off of the main image and flashing it onto an external HD, so the SD is really only used for booting.

Hi Oliver,

Sorry for the poor choice of words. I meant the Ubuntu Phone.

In terms of wearing out SD cards -- yes it's a very real problem. We see this very frequently in Screenly (despite only using good quality SD cards). While we currently run on Raspbian and have reduced the writes significantly by using tmpfs whenever possible (even for logs), we still see it frequently.

In terms of what the actual optimizations were -- I'm not sure. Manik mentioned that there were some detection mechanism, among some other tweaks to extend the lifespan of the storage.

@Kyle our application isn't very write heavy, so it's mostly system operations that I'm worried about. Perhaps it would make sense to provide the option to set noatime or similar for the application store.

no, there are no specific mechanisms except that we make sure the defaults in all packages assembling the phone image are set up in a way they do not do any excessive writing. as i said, the same happened for snappy though (many people that designed the phone foundation layer are todays snappy developers ;)).

even on the phone there is no protection from having a go-wild-app that a user installed from the store though. what we can guarantee is that the OS itself definitely wont wear out MMCs quickly and that goes for the snappy OS too ...

regarding an app snap like screenly i think kyle is right, the app should simply be able to use an externally attached device (though are USB sticks really wearing out less under the same circumstances ?)

I see. I was just relaying what I heard. Hence I have no insight into the code base.

In terms of Screenly, it's not very write intense. Even the most active users (i.e. customers who update their playlist very often) wouldn't cause more than 10-20 or writes per day. All assets are also cached on disk. As such, tit's mostly reads.

Hence, assuming the system is conservative in writes, and that we can log to tmpfs (with a remote syslog target), we should be fine.

alowing mount options for an exernal drive should definitely be considered (note though that ubuntu already defaults to relatime everywhere, the gain wont be *that* big when switching to noatime)

> @Kyle our application isn't very write heavy, so it's mostly system operations that I'm worried about.

Note that the writable partition is used for all writes, including system operations.

unfortunately, i missed this bug in my email. anyway, the mechanism i mentioned that could be useful is to use UBIFS, which is specifically designed for raw flash memory media and helps with wear leveling. this is exactly what OpenWRT uses in devices where wear leveling is a real concern.

@manik, yes, ubifs is a good choice for raw NAND flash devices ... if you actually have hardware with such devices ... (they got pretty rare since they are a multitude more expensive than EMMC which is the current quasi standard)

note though that the choice of filesystem does not actually change anything regarding the writes the os does, more important here is the wear levelling in the controller, a better and more expensive controller can definitely extend the lifetime of EMMC flash massively, this is again a matter of money though. In typical hobbyist HW like the raspberry Pi you will not find such HW though.

beyond this you can adjust caching mechanisms and writeback values of the kernel at cost of performance (afaik the kernel snap should allow setting sysctl values, so an appliance builder can ship his own kernel snap with the wanted adjustments (talk to the core team about this though, not sure how/if that feature is there yet))

so to expand my last comment, lets take a look at todays defaults and what we can do here:

by default ubuntu mounts all disks with "relatime" since the "dapper" release (this is a little less conservative than noatime but will not break applications that need the timestamps like noatime typically does) so here is not much to be gained.

our disk scheduler defaults to deadline currently, that offers the write_expire setting which we could probably tweak a little higher (default: 500ms) at the cost of ram and data integrity.

there are a few vm cache settings we could tweak in the rpi gadget (again at the cost of ram):

vm.dirty_writeback_centisecs = 60000 # wakeup time for kernel cache flushing (default: 500)
vm.dirty_ratio = 40 # absolute % of ram that can be used for cache (default: 20%)
vm.dirty_background_ratio = 20 # % of ram used before flushing cache (default is 10%)

will take care that there are less writes but as with the scheduler changes you risk data loss at power loss (data is kept longer in ram and flushed less often).

beyond this, the only thing i see that could massively improve write behaviour would be dropping syslog ... but if you want remote logging this is the only way to get it ...

... and i just noticed that the above was probably not clear, but UBIFS is not an option on SD cards which are MMC devices, not raw flash devices ...

Setting this to Won'tFix. If we do revisit this and decide there's something we can do, we can change that ...