losetuping files in tmpfs fails?

losetuping files in tmpfs fails?

[Andy Gaynor]

Whilst trying to figure out why my dang stripes won't persist (a separate
but worrisome issue), I wrote a dittie which creates a couple junk files in
/tmp (tmpfs), associates loop devices with them, whoops, losetup craps out.

  /home/root# losetup -d /dev/loop/5 2>/dev/null # Free /dev/loop/5

  /home/root# cd /home/root             # Go home
  /home/root# mount | grep /home        # Filesystem is ...
  /dev/md/8 on /home type reiserfs (rw) #   reiserfs
  /home/root# echo foo > foo            # Create file foo
  /home/root# losetup /dev/loop/5 foo   # Give foo to /dev/loop/5
  /home/root# losetup -d /dev/loop/5    # Free /dev/loop/5
  /home/root# rm foo                    # Remove foo

  /home/root# cd /tmp                   # Go to /tmp
  /tmp# mount | grep tmp                # Filesystem is ...
  tmpfs on /tmp type tmpfs (rw)         #   tmpfs
  /tmp# echo foo > foo                  # Create file foo
  /tmp# losetup /dev/loop/5 foo         # Give foo to /dev/loop/5
  ioctl: LOOP_SET_FD: Invalid argument  #   DISCO!!!                <o >  <o >
  /tmp# rm foo                          # Remove foo

    Version information:

  Distribution: Debian Woody, up-to-date as of a week ago
  Kernel: Linux 2.4.17

    I don't subscribe to linux-kernel@vger.kernel.org.  If you want me to
see a message, please mail it to me.  If my site is down, send to
stupid_email_tricks@mailandnews.com.  And bonk my administrator with a
wiffle bat.

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

Re: losetuping files in tmpfs fails?

[Andrew Morton]

Andy Gaynor wrote:
> 
> Whilst trying to figure out why my dang stripes won't persist (a separate
> but worrisome issue), I wrote a dittie which creates a couple junk files in
> /tmp (tmpfs), associates loop devices with them, whoops, losetup craps out.
> 
> ...
>   /tmp# mount | grep tmp                # Filesystem is ...
>   tmpfs on /tmp type tmpfs (rw)         #   tmpfs
>   /tmp# echo foo > foo                  # Create file foo
>   /tmp# losetup /dev/loop/5 foo         # Give foo to /dev/loop/5
>   ioctl: LOOP_SET_FD: Invalid argument  #   DISCO!!!                <o >  <o >

Yup, tmpfs doesn't provide some of the facilities which the
loop driver requires.   Specifically, prepare_write() and 
commit_write().  

Probably it's not too hard to change loop to use generic_file_write(),
and it will then permit tmpfs file-backed loop mounts.

It's not obvious that there's a burning need to support loop-on-tmpfs
though, is there?

-

Re: losetuping files in tmpfs fails?

[David Golden]

On Thursday 03 January 2002 23:10, Andrew Morton wrote:
> It's not obvious that there's a burning need to support loop-on-tmpfs
> though, is there?
>

/sbin/mkinitrd and /sbin/mkinitd_helper in major distros tend to loop back on 
files called  /tmp/initird.blah to make the images.

Re: losetuping files in tmpfs fails?

[Andreas Dilger]

On Jan 03, 2002  15:10 -0800, Andrew Morton wrote:
> Andy Gaynor wrote:
> > Whilst trying to figure out why my dang stripes won't persist (a separate
> > but worrisome issue), I wrote a dittie which creates a couple junk files in
> > /tmp (tmpfs), associates loop devices with them, whoops, losetup craps out.
> > 
> > ...
> >   /tmp# mount | grep tmp                # Filesystem is ...
> >   tmpfs on /tmp type tmpfs (rw)         #   tmpfs
> >   /tmp# echo foo > foo                  # Create file foo
> >   /tmp# losetup /dev/loop/5 foo         # Give foo to /dev/loop/5
> >   ioctl: LOOP_SET_FD: Invalid argument  # DISCO!!!          <o >  <o >
> 
> Yup, tmpfs doesn't provide some of the facilities which the
> loop driver requires.   Specifically, prepare_write() and 
> commit_write().  
> 
> Probably it's not too hard to change loop to use generic_file_write(),
> and it will then permit tmpfs file-backed loop mounts.
> 
> It's not obvious that there's a burning need to support loop-on-tmpfs
> though, is there?

Well, if you are using tmpfs as your /tmp filesystem (presumably not
such a strange situation given the name ;-), then any tool which creates
a loopback in /tmp will break.  Good examples would be mkinitrd, or
anything that is generating a floppy image (e.g. Linux Router Project
floppy, boot floppy tools, etc).

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/

Re: losetuping files in tmpfs fails?

[Andy Gaynor]

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

Re: losetuping files in tmpfs fails?

[Ishan Oshadi Jayawardena]

Greetings.

Andrew Morton wrote:

> Yup, tmpfs doesn't provide some of the facilities which the
<snip>
> It's not obvious that there's a burning need to support loop-on-tmpfs
> though, is there?

	No, there isn't. I noticed this myself a few months back, but didn't
complain because, well, the purpose of tmpfs is to provide support for
POSIX shared memory, right? (At least according to Configure.help).
{If,/ Because} tmpfs does that correctly, it's not broken.
	The only app I've encountered that breaks with this is mkinitrd and
associates, but it should at least attempt to fallback to the user's
home directory IMHO (without complaining "you're all out of loop
devices" - an old Redhat mkinitrd).

Cheerio!

	 - ioj

Re: losetuping files in tmpfs fails?

[Frédéric L. W. Meunier]

On a side note, why do I need to use losetup -d after umount
when /etc/mtab is a symlink to /proc/mounts ?

mount or loop "feature" ?

-- 
0@pervalidus.{net, {dyndns.}org} Tel: 55-21-2717-2399 (Niterói-RJ BR)

Re: losetuping files in tmpfs fails?

[H. Peter Anvin]

Followup to:  <3C35F8B2.98763627@sltnet.lk>
By author:    Ishan Oshadi Jayawardena <ioshadi@sltnet.lk>
In newsgroup: linux.dev.kernel
> 
> 	No, there isn't. I noticed this myself a few months back, but didn't
> complain because, well, the purpose of tmpfs is to provide support for
> POSIX shared memory, right? (At least according to Configure.help).
> {If,/ Because} tmpfs does that correctly, it's not broken.
> 

That was the original reason for it, when it was called "shmfs".  It
has become more than that, due to the fairly clever observation that
"shmfs" already supported virtually everything needed for a swappable
temporary-storage general filesystem.

	-hpa

P.S. On kernel.org, I was forced to hack tmpfs so that it returns a
nonzero size for directories; otherwise "make distclean" breaks for
older Linux kernels, and the incdiff robot that runs on kernel.org
relies on this operation working correctly.  It would be a good thing
if tmpfs could account for the amount of memory consumed by
directories, etc.
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>

Re: losetuping files in tmpfs fails?

[H. Peter Anvin]

Followup to:  <20020105215147.GH136@pervalidus>
By author:    =?iso-8859-1?B?RnLpZOlyaWMgTC4gVy4=?= Meunier <0@pervalidus.net>
In newsgroup: linux.dev.kernel
>
> On a side note, why do I need to use losetup -d after umount
> when /etc/mtab is a symlink to /proc/mounts ?
> 
> mount or loop "feature" ?
> 

/proc/mounts, unlike /etc/mtab, doesn't tell umount(8) that this was a
loopback created by mount(8) as opposed to a preexisting loopback
created by losetup(8).

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>

Re: losetuping files in tmpfs fails?

[Guest section DW]

On Sat, Jan 05, 2002 at 07:51:47PM -0200, F.W. Meunier wrote:

> On a side note, why do I need to use losetup -d after umount
> when /etc/mtab is a symlink to /proc/mounts ?
> 
> mount or loop "feature" ?

mount will do losetup -d at umount time if and only if it did losetup
at mount time, as is recorded in /etc/mtab. With a symlink that info
is lost. See mount(8).