Re: losetuping files in tmpfs fails?

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?

[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>

tmpfs accounting (was: losetuping files in tmpfs fails?)

[Christoph Rohland]

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

Re: tmpfs accounting (was: losetuping files in tmpfs fails?)

[H. Peter Anvin]

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