Subject: Re: tmpfs and union mounts
To: Steven M. Bellovin <firstname.lastname@example.org>
From: Marcin Jessa <email@example.com>
Date: 10/15/2005 22:10:39
On Sat, 15 Oct 2005 14:06:34 -0400
"Steven M. Bellovin" <firstname.lastname@example.org> wrote:
: In message <email@example.com>,
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