mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andy Gaynor <silver@silver.unix-fu.org>
To: Andrew Morton <akpm@zip.com.au>
Cc: linux-kernel@vger.kernel.org
Subject: Re: losetuping files in tmpfs fails?
Date: Fri, 04 Jan 2002 05:38:30 -0500	[thread overview]
Message-ID: <3C358626.B88DA942@silver.unix-fu.org> (raw)
In-Reply-To: <3C2F0AEE.ACABAAFA@silver.unix-fu.org> <3C34E4DF.F439FD70@zip.com.au>

Thanks all for your responses to ...

silver@silver.unix-fu.org (Yers truly) wrote:
> [Lookey, I can't loop to files in tmpfs!]

Before trying out a new kernel feature, I give the docs at least a quick look
for bugs and warnings.  The higher the signal-to-noise ratio, the closer I
look.  tmpfs.txt is conversational, so I only gave it a cursory scan.  The
notes on the loop restriction are kind of obscured.  The first is the second
line of "usage" 3.  Having read the first line, completely innocuous and
unrelated to the restriction, I moved on.  The second was "todo" 2 at the very
bottom, and todos aren't usually very interesting to first-time users.  This is
an important restriction with no obvious justification (the cynical might even
call such a bug), and should be prominently advertised.

akpm@zip.com.au (Andrew Morton) wrote:
> It's not obvious that there's a burning need to support loop-on-tmpfs though,
> is there?

Completeness is enough.  /tmp is a general purpose area and should generally
work.  Given /tmp's transient nature, it's quite reasonable to trade away
persistence for other features, including speed and flexibility.  However,
there is no obvious justification for trading away other features, like the
ability to contain the objects of loops.

    As for specific need, it's common practice to create temporary filesystems
in a file before sending them to removable volumes.  The activity on such
filesystems is usually intensive and short-lived, making them ideal candidates
for tmpfs's features.  It pleases me to get better mileage from my generous
swap partitions, which occupy prime prime real estate on my hard drives: fast
low-order fast locations strategically placed between system and data areas.

Regards, [Ag]   Andy Gaynor   silver@silver.unix-fu.org

  parent reply	other threads:[~2002-01-04 11:14 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-12-30 12:39 Andy Gaynor
2002-01-03 23:10 ` Andrew Morton
2002-01-03 23:42   ` David Golden
2002-01-03 23:42   ` Andreas Dilger
2002-01-04 10:38   ` Andy Gaynor [this message]
2002-01-04 18:47 Ishan Oshadi Jayawardena
2002-01-05 23:18 ` H. Peter Anvin
2002-01-05 21:51 Frédéric L. W. Meunier
2002-01-05 23:20 ` H. Peter Anvin
2002-01-06  0:15 ` Guest section DW

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=3C358626.B88DA942@silver.unix-fu.org \
    --to=silver@silver.unix-fu.org \
    --cc=akpm@zip.com.au \
    --cc=linux-kernel@vger.kernel.org \
    /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

all inboxes | Powered by JetHome®