Re: best way of logging on flash based systems

[matthew sporleder <msporleder%gmail.com@localhost>]

On Mon, Jun 21, 2010 at 3:19 PM, Greg A. Woods <woods%planix.com@localhost> 
wrote:
> At Thu, 10 Jun 2010 16:33:45 -0400, matthew sporleder 
> <msporleder%gmail.com@localhost> wrote:
> Subject: Re: best way of logging on flash based systems
>>
>> I don't think your changes will last through a reboot.  I think you
>> would need to modify the lower layer of the union on shutdown.  But I
>> may be wrong.
>
> Indeed, changes to the upper layer will be lost on reboot if they're
> only in a TMPFS or MFS.
>
> I've been thinking for a long time that it would be cool to have some
> simple extensions to UNIONFS that would allow a "commit" command to try
> to sync/flush/copy-down changes in the upper layer to the lower layer,
> perhaps with some additional, optional, simple, version keeping tricks
> too.
>
> (Though I suppose if you keep the lower layer visible at another
> location in the filesystem through a loopback mount then any form of
> backup and versioning tools could be used.  It would still be nice
> though to be able to robustly re-sync the upper layer of the UNIONFS so
> as to toss out all changes that are now available on the lower layer,
> and by robustly I mean in a running system with open files.)
>
>
>> I've actually had one or two problems with the unionfs method and
>> would recommend something more like the method found here:
>> http://mspo.com/blog/2009/05/netbsd-seedtmpfs-tool-for-easier.html
>
> You mean the part at the top where it says to ignore the rest and just
> make a decent-sized MFS and then union-mounts it over /var(/log)?  :-)
>
> Seriously, what problems have you had with the unionfs method?  PR#s?
> Do these problems apply specifically to use of UNIONFS for system
> directories like /var (or /etc)?


kern/41678 was my biggest issue.  It creates an inconsistent user experience.


>
> Also, why bother hiding the TMPFS partitions?
>


I don't like to see multiple presentations of the same thing in df.


> Oh, and that bug with "mount -a" could be mitigated by having the
> mount_seed_tmpfs script check to see if the tmpfs already exists and is
> mounted, no?
>


Probably, but I wasn't going to work on it unless anyone showed
interest.  The two people I know who use the extract-on-boot method
were already happy with their own home-grown systems and netbsd wasn't
including one in base to supersede them, so my own solution is just a
blog post for now.

I preferred my way because it used mount instead of an rc script.