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

[James Knowles]

>I still think this is part of the filesystem.  
>

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....

>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.

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.

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.

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.

What you see there is not filesystem design, but two valid expressions 
of the same computer science concept.

Anyhow, you know what's in your head. I'm just guessing; trying to make 
rational sense out of what I interpret.