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)?
Also, why bother hiding the TMPFS partitions?
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?
--
Greg A. Woods
Planix, Inc.
<woods%planix.com@localhost> +1 416 218 0099 http://www.planix.com/
Attachment:
pgpXShhI2pEy5.pgp
Description: PGP signature