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 [email protected]. If you want me to
see a message, please mail it to me. If my site is down, send to
[email protected]. And bonk my administrator with a
wiffle bat.
Regards, [Ag] Andy Gaynor [email protected]
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?
-
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.
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/
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
Thanks all for your responses to ...
[email protected] (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.
[email protected] (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 [email protected]
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)
Followup to: <[email protected]>
By author: Ishan Oshadi Jayawardena <[email protected]>
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.
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <[email protected]>
Followup to: <20020105215147.GH136@pervalidus>
By author: =?iso-8859-1?B?RnLpZOlyaWMgTC4gVy4=?= Meunier <[email protected]>
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
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <[email protected]>
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).
Hi Peter,
On 5 Jan 2002, H. Peter Anvin wrote:
> 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.
I would not like to add the real size without a bigger goal (I would
not see a problem with a fake size).
On the other side I could imagine that we make the directories tmpfs
files which hold the swap vectors of the real tmpfs files of this
directory. With this we would gain swappable meta data for tmpfs and
had a real size for the directories for free.
Greetings
Christoph
Christoph Rohland wrote:
>
> I would not like to add the real size without a bigger goal (I would
> not see a problem with a fake size).
>
It defeats the filesystem size limit, and makes it possible to an
unprivileged user to consume unlimited amounts of kernel memory.
-hpa