public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  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