/tmp, /var/tmp and tmpfs (was: Re: [PATCH] ds_backup - major rework)

[Martin Langhoff]

Michael Stone's review of my recent patches to ds-backup raised some
issues about creating temp files (that wear NAND out) and about
successful backups on a full or otherwise RO NAND. See below...

On Mon, Jun 16, 2008 at 5:45 PM, Martin Langhoff
<martin.langhoff at gmail.com> wrote:

>> Are we concerned about the cleanup code failing, for example because
>> permissions were changed on the ds_path dir? If it permanently failed
>> then I think our backup script would also permanently fail, which
>> doesn't seem quite right. (If something's broken with my permissions,
>> then I _want_ my backup script to take what data it can get and move it
>> off the system, right?)
>
> Good point. This part of the code is removed, but I haven't made it a
> point to ensure that the code can backup a RO homedir. Actually, we
> aren't well setup for a RO root fs at all (should an error kick us
> into ro), /tmp is not a tmpfs!

To address both issues - RO/fulldisk-tolerant backup and less NAND
wear, we need /tmp to be a tmpfs. There are some risks in that -
namely, that programs might be using /tmp to write large stuff. That
is a pretty common bug in the unix world - mkstemp and friends to
straight for /tmp but for large stuff, /var/tmp is the place. Many
systems, old and new, use some kind of ramdisk for /tmp -

I would suggest a quick audit of likely suspects that we don't want to
see break (ie: olpc-update).

In any case, here's the bug:

     http://dev.laptop.org/ticket/7300

cheers,



m
-- 
 martin.langhoff at gmail.com
 martin at laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff