From: Sean Hunter <sean@dev.sportingbet.com>
To: Christoph Rohland <cr@sap.com>
Cc: Denis Vlasenko <vda@port.imtp.ilyichevsk.odessa.ua>,
Geoffrey Gallaway <geoffeg@sin.sloth.org>,
linux-kernel@vger.kernel.org
Subject: Re: Ramdisks and tmpfs problems
Date: Wed, 10 Apr 2002 15:49:38 +0100 [thread overview]
Message-ID: <20020410154938.G4493@dev.sportingbet.com> (raw)
In-Reply-To: <20020409144639.A14678@sin.sloth.org> <20020410084505.A4493@dev.sportingbet.com> <200204101028.g3AAS2X05866@Port.imtp.ilyichevsk.odessa.ua> <20020410114521.C4493@dev.sportingbet.com> <m3662zzs6y.fsf@linux.wdf.sap-ag.de>
On Wed, Apr 10, 2002 at 01:52:37PM +0200, Christoph Rohland wrote:
> Hi Sean,
>
> On Wed, 10 Apr 2002, Sean Hunter wrote:
> >> /dev is for devices, why do you use it for mounting filesystems?
> >
> > Normally yes, but the tmpfs provides posix shared memory semantics
> > and thus /dev/shm is the "normal" place to mount it. Don't blame
> > me.
>
> Yes, and he does not want to use it for POSIX shared mem, but as a
> local filesystem. So he should mount it where he needs it and
> definitely not misunse the posix mount for different things.
The whole point was that he was doing extra copies and mount/unmounts that he
didn't need. He couldn't just mount it in /etc/ in the first place because he
needed to copy stuff from the underlying fs that was there onto the tmpfs.
point -------------------------->
<------------- Christoph Rohland
Which is why I proposed two mounts:
(1) A mount under /dev/shm reflecting its nature and role as providing posix
shared mem (convenient because its not /etc where he already _has_ files)
(2) A bind mount under /etc reflecting its nature and role as providing a
ram-based file system (convenient because that's where he actually wants the fs
to be)
I just suggested that by mounting it what has been established as the canonical
place for mounting tmpfs and using a bind mount he doesn't need the extra
copies/mounts.
Sheesh. Next thing you'll be asking if a filesystem can have buddha nature.
Sean "Mu" Hunter
next prev parent reply other threads:[~2002-04-10 14:47 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-04-09 18:46 Ramdisks and tmpfs problems Geoffrey Gallaway
2002-04-09 19:49 ` Andrew Morton
2002-04-09 21:18 ` Geoffrey Gallaway
2002-04-10 7:45 ` Sean Hunter
2002-04-10 15:31 ` Denis Vlasenko
2002-04-10 10:45 ` Sean Hunter
2002-04-10 11:52 ` Christoph Rohland
2002-04-10 14:49 ` Sean Hunter [this message]
2002-04-10 11:01 ` Denis Vlasenko
2002-04-10 14:23 ` Update - " Geoffrey Gallaway
2002-04-10 14:52 ` Sean Hunter
2002-04-10 15:01 ` Geoffrey Gallaway
2002-04-10 16:03 ` Sean Hunter
2002-04-11 11:03 ` Denis Vlasenko
2002-04-11 15:47 ` Christoph Rohland
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20020410154938.G4493@dev.sportingbet.com \
--to=sean@dev.sportingbet.com \
--cc=cr@sap.com \
--cc=geoffeg@sin.sloth.org \
--cc=linux-kernel@vger.kernel.org \
--cc=vda@port.imtp.ilyichevsk.odessa.ua \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox