[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 <woods%planix.com@localhost>
> 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
> (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.
Main Index |
Thread Index |