[WBEL-users] OT: Fwd: Re: Booting linux host, getting error message (SOLVED)

[A Streetcar Named]

On Thu, 12 Aug 2004 21:19:44 -0600, James Knowles
<jamesk@ifm-services.com> wrote:
> I came up with a solution. I'm mounting /var/run as tmpfs, so it's
> automatically cleared upon shutdown (including reboot).
> 
> I added the following to /etc/fstab:
> none       /var/run        tmpfs   defaults    1 2
> 
> There's an article on this nifty trick:
> http://www-106.ibm.com/developerworks/library/l-fs3.html

>From the article:
--- cut here ---
Dynamic filesystem size
You're probably wondering about how big that tmpfs filesystem was that
we mounted at /mnt/tmpfs, above. The answer to that question is a bit
unexpected, especially when compared to disk-based filesystems.
/mnt/tmpfs will initially have a very small capacity, but as files are
copied and created, the tmpfs filesystem driver will allocate more VM
and will dynamically increase the filesystem capacity as needed. And,
as files are removed from /mnt/tmpfs, the tmpfs filesystem driver will
dynamically shrink the size of the filesystem and free VM resources,
and by doing so return VM into circulation so that it can be used by
other parts of the system as needed. Since VM is a precious resource,
you don't want anything hogging more VM than it actually needs, and
the great thing about tmpfs is that this all happens automatically.
--- cut here ---

I'm not sure if he's correct here.  My understanding is 
* that the tmpfs filesystem will have a certain capacity at mount time
(whatever is specified by size= parameter, or 1/2 physical RAM by
default), although it will only actually occupy a tiny amount of that
VM at first.

* As files are copied and created, more VM is occupied, but the
capacity of the filesystem remains unchanged although it can be
dynamically resized with mount -o remont,size=....  The significance
of this is that the maximum amount of VM that will be consumed is
bounded by the size= parameter, and that it cannot grow without bounds
to consume all of your VM

* As files are removed or the unmapped, the space is not returned to
the VM because the semantics of a file system are such that the data
remains in place even if it's not utilised, available for undelete or
whatever.  This is the reason why there is a kernel patch to introduce
/dev/anon functionality - see
http://user-mode-linux.sourceforge.net/devanon.html

I might have the wrong understanding, especially on that last point. 
Hopefully someone will correct me if so =)