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

[A Streetcar Named]

On Sat, 14 Aug 2004 13:06:09 -0600, James Knowles
<jamesk@ifm-services.com> wrote:
> 
> You'll really have to explain yourself here. I think you're confusing
> two completely separate things. I designed and worked with filesystems
> about 20 years ago, so unless there's been some radical advance in
> theory that I'm not aware of... or if I'm just not getting what you're
> saying....

I could be wrong.  I make no claims to being a filesystems guru =)

> >The fact that tmpfs fuzzes over medium and filesystem makes it confusing, but if we created ext2/3, reiserfs, etc. on a tmpfs medium, they still leave
> >data around persistently.
> OK. This is where you're confusing things or I'm not understanding. As I
> read this, it makes no sense whatsoever.
> 
> This may come across as rather pointed. I'm not trying to be rude or
> mean, I'm just trying to understand what you're saying.
> 
> 1) tmpfs is not a medium. tmpfs is not a block-special device. It is a
> filesystem like ext3fs or reiserfs. Huge difference.
> 
> Observe /etc/fstab:
> none                    /dev/shm                tmpfs   defaults        0 0
> 
> Field #1 ("none") is the block-special device for the file system.
> Field #2 ("/dev/shm") is the mount point.
> Field #3 ("tmpfs") is the filesystem type, such as ext3, or reiserfs.
> 
> 2) tmpfs does not use an underlying physical medium, nor does it use a
> block-special device. See "none" in /etc/fstab above.

I asserted that tmpfs fuzzes over medium and filesystem because they
seem to be inextricably tied together.  As you say, tmpfs does not use
block devices as a medium.  You CAN mount other standard filesystems
from a file as a medium via loopback; AFAIK tmpfs will only use your
VM as a medium.

> 3) How in the name of heaven do you create another filesystem on top of
> tmpfs? This is akin to saying "if we created reiserfs on an ext3fs
> medium," which is utter garbage from where I stand. I've tried several
> methods to lay another filesystem on tmpfs, each of them either were not
> permitted or immediately locked up the computer.
> 
> Are you referring to creating a loopback device on tmpfs that contains a
> regular filesystem? If so, then your assertion that "they still leave
> data around persistently" is a false conclusion based on faulty
> assumptions.

Yes, this was what I was referring to.
 
> The underlying filesystem (tmpfs) only sees an ordinary file (mounted as
> a loopback device). It has no concept of the ordinary file as a
> filesystem, and thus cannot know when a file has been freed, and
> therefore that part of the ordinary file can be released from the list
> of occupied inodes. All it sees is a file -- a block of raw memory that
> another process is manipulating.

Yes, I think this is what /dev/anon does in that it can release blocks
of a file back to the VM when it's unmap'ed - it's right for the
special requirements of UML, but it's not the correct behaviour of
standard filesystems.
 
> Now, if one could put ext[23]fs or reiserfs on the virtual memory
> "medium" that tmpfs uses, then when a file were deleted, memory would be
> freed just as in tmpfs. That is because the inodes have been released.
> If one were to mark them as unused and ignore the pointer, which one may
> do with magnetic media, one would create a massive series of memory leaks.

I don't know.  We're fuzzing over the virtual memory medium that tmpfs
uses because it's tied into tmpfs, and we simply can't put any other
filesystem onto it directly.  If we create a sparse file and mounted a
standard filesystem on it via loopback, it exhibits some of the
characteristics of tmpfs (fixed maximum size, occupies little
'backing' space at first), except that the space occupied by a file
remains occupied even after the file is deleted.  Is this because the
filesystem doesn't find some way of returning the now-unused space, or
because the backing store is persistent?  All filesystems rely on
persistence of their backing store (magnetic media, virtual memory,
etc) or data could be gone as soon as it is written.  My layman's view
is that tmpfs is able to release space back to the backing store not
because it is actually VM underlying, but because it is somehow able
to rearrange itself or indicate to the store that certain portions are
now unused.  If we could somehow put another filesystem on the same
backing store, the filesystem still has to indicate which portions are
now safe to be reclaimed.

Put another way, I _believe_ (but could be wrong) that ramfs presents
a form of virtual memory medium as a block device on top of which you
can layer standard filesystems and that deleting files there does not
return space to the VM because the filesystem is still holding on to
it...  If a hypothetical filesystem is created that can indicate to
the backing store that an area should be treated as being sparse, it
could become a loopback version of tmpfs