On Sat, 15 Oct 2005 14:06:34 -0400
"Steven M. Bellovin" <smb@cs.columbia.edu> wrote:

: In message <1129396578.894858.2882.nullmailer@yamt.dyndns.org>,
YAMAMOTO Takash : i writes:
: >> I'm trying to do a union mount involving a tmpfs file system.  
: >> Unfortunately, I'm getting 'operation not supported'.  Is it
supposed : >> to work?
: >
: >(assuming you mean unionfs)
: >
: >no.  tmpfs doesn't have whiteout.
: >
: 
: That's too bad.
: 
: I'm putting together a Soekris system, based on the advice given at
: http://www.netbsd.org/~jschauma/netbsd-solidstate.html.  For a number 
: of reasons, that document suggests mfs filesystems for /dev and /var, 
: and (for /var) extracting a tarball of the real /var into the mfs
file : system.  

Whatever the doc say the best way is to create a kernel image which
will include root file system, boot your system and mount the file
system in memory.
Create a script which will automatically format your CF and install
bootstrap software and copy your new file system to it.
The new system will mount your /var as tmpfs with a fixed memory limit
so it never goes bananas.
I dont suspect you to boot your soekris every minute and wear out your
CF (they can be written to a lot these days) so having /dev on your /
mounted as ffs should not cause any problem.

: I'd like to do things differently if possible.  First, of course, I'm 
: using tmpfs instead of mfs; the memory efficiency is very important
: on a machine with only 128M of RAM and no swap disk.  Beyond that, if
: I could do a unionfs mount of a tmpfs on top of /var and /dev, I
: could skip the extraction; it would all just work.

Could you please explain me what extraction you're talking about ?
I do not quite understand what you are trying to achieve here.

: /dev presents other problems.  If I create new entries by running 
: MAKEDEV inside the tmpfs or mfs file system, I can't do
: 
: 	mount -uw /
: 
: because it complains "specified device does not match mounted device".
: For that matter, it wasn't clear to me why I needed a writable /dev, 
: until I learned that it's not possible to open for output a device 
: special file on a read-only file system.  I don't see any reason to 
: enforce that policy -- a device file isn't a resource, it's a pointer 
: to a resource whose read-only status is not coupled to that of the 
: containing filesystem -- but it isn't clear to me if that's a 
: difficult-to-avoid consequence of other code.  The other problem with
a : non-writable /dev is that various parts of the system can't do chown
() : calls on, say, ttys; for an appliance box, that's a lot less
relevant, : as long as it doesn't block console and ssh login.
: 
: 		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb
: 
: