NetBSD-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: best way of logging on flash based systems

On Mon, Jun 21, 2010 at 3:19 PM, Greg A. Woods <> 
> At Thu, 10 Jun 2010 16:33:45 -0400, matthew sporleder 
> <> 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:
> 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.

Home | Main Index | Thread Index | Old Index