FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 11-13-2011, 07:32 AM
Bastien ROUCARIES
 
Default /tmp as tmpfs and consequence for imaging software

On Sat, Nov 12, 2011 at 11:12 PM, Samuel Thibault <sthibault@debian.org> wrote:
> Adam Borowski, le Sat 12 Nov 2011 23:08:08 +0100, a crit :
>> You need to increase the swap size by the amount you'd use for /tmp.
>
> Well, the idea of such case is precisely to *not* use swap, but real
> disks. Such software already know how to manage its memory and
> disk-backed memory (thusly stored in /tmp)

I agree with samuel here. Science software know how to use disk baked
file. And are better than general software. I will open rcbug to use
/var/tmp instead of /tmp in this case. But it is a pitty.

Bastien
> Samuel
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> Archive: http://lists.debian.org/20111112221236.GT4465@type.famille.thibault.fr
>
>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CAE2SPAZ=TdhhzRgg8mwW5jHjukSaeOQTu-O2w6W=zCHonBaA5Q@mail.gmail.com">http://lists.debian.org/CAE2SPAZ=TdhhzRgg8mwW5jHjukSaeOQTu-O2w6W=zCHonBaA5Q@mail.gmail.com
 
Old 11-13-2011, 07:40 AM
Bastien ROUCARIES
 
Default /tmp as tmpfs and consequence for imaging software

On Sat, Nov 12, 2011 at 11:25 PM, Josselin Mouette <joss@debian.org> wrote:
> Le samedi 12 novembre 2011 * 23:12 +0100, Samuel Thibault a écrit :
>> Adam Borowski, le Sat 12 Nov 2011 23:08:08 +0100, a écrit :
>> > You need to increase the swap size by the amount you'd use for /tmp.
>>
>> Well, the idea of such case is precisely to *not* use swap, but real
>> disks. Such software already know how to manage its memory and
>> disk-backed memory (thusly stored in /tmp)
>
> Practically speaking, the only significant difference is that files are
> not forced to disk as early. Otherwise, if you have a large enough swap,
> pages of a file on a tmpfs that are not used enough will be swapped. And
> pages of a file on a regular filesystem that are used enough will be
> kept in the buffer cache.

No it is not true. Science and imaging software are better to use true
disk baked file. For instance, if I want ot invert a big matrix they
are pretty good algorithm that force only some part of the file to be
keep on disk. They known better than kernel when to put somepart on
the data on the slow disk.

Using tmpfs under /tmpfs you break assumptions on the life expendancy
of memory object. And you slow down this kind of software (that work
perfecly for 40 years).

> OTOH, for a wide range of applications that do a lot of small writes,
> using tmpfs is a huge gain.

Yes for desktop. Not for software that know ho to use backed disk file.

And do not ask user to choose. Imageging software and movie maker
software have the same requirement than high performance science
software.
They need file backed.

Now that are the solution ? We could not increase tmpfs over 50% to
70% of physical ram without deadlock (OOM and so on). And it is not
enought for your use. Should we use /var/tmp ? But it does not fit
due to "Files and directories located in /var/tmp must not be deleted
when the system is booted" (FHS). Whereas this kind of software want
to be non persistant and tru file backed.

Any suggestion is welcome

> -
> *.'`. * * *Josselin Mouette
> : :' :
> `. `'
> *`-
>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/CAE2SPAYW_-JG9V3grgfQ1-c_nDu_GCqvub+kPnQP�BK9g@mail.gmail.com
 
Old 11-13-2011, 07:44 AM
Bastien ROUCARIES
 
Default /tmp as tmpfs and consequence for imaging software

On Sat, Nov 12, 2011 at 11:35 PM, Ben Hutchings <ben@decadent.org.uk> wrote:
> On Sat, 2011-11-12 at 22:24 +0100, Bastien ROUCARIES wrote:
>> Hello,
>>
>> Recently debian put /tmp under tmpfs.
>>
>> Even if it increase reponsivness under desktop, it ruin completly
>> sciene and imaging software that do some off loading on /tmp.
>>
>> For instance using gscan2pdf on 60pages document create more than 1.2G
>> of image file under /tmp and crash du to missing space.
>>
>> What are the solution for this kind of problem ?
>
> This problem has little to do with use of tmpfs; it is not reasonable to
> assume that /tmp has that much space. *Programs should generally allow
> use of /tmp to be overridden by $TMPDIR and should handle disk-full
> errors gracefully.

Yes I agree. But wich $TMPDIR should we use ? /var/tmp does not fit
because it is not cleaned at boot. And the problem is the default have
changed. I do not excuse sloppy programmer. but we need something like
a standard tmp dir that is file backed and cleaned every boot.

Bastien

> Ben.
>
> --
> Ben Hutchings
> The program is absolutely right; therefore, the computer must be wrong.
>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CAE2SPAbLfnpapDfmPFe+HtzJWbebjSNpcs7iBeP675z9Nx5bS w@mail.gmail.com">http://lists.debian.org/CAE2SPAbLfnpapDfmPFe+HtzJWbebjSNpcs7iBeP675z9Nx5bS w@mail.gmail.com
 
Old 11-13-2011, 07:50 AM
Josselin Mouette
 
Default /tmp as tmpfs and consequence for imaging software

Le dimanche 13 novembre 2011 * 09:40 +0100, Bastien ROUCARIES a écrit :
> No it is not true. Science and imaging software are better to use true
> disk baked file. For instance, if I want ot invert a big matrix they
> are pretty good algorithm that force only some part of the file to be
> keep on disk. They known better than kernel when to put somepart on
> the data on the slow disk.

The application might know better its usage profile, but the kernel
knows better how the actual hardware behaves. This is why there are now
some APIs to give hints to the kernel instead of assume the application
can deal with everything by itself.

> And do not ask user to choose. Imageging software and movie maker
> software have the same requirement than high performance science
> software.

Having to deal with quite a lot of HPC software, I can assure you that
most of such applications do not know how to use disk or memory
correctly. They see considerable speedup when using tmpfs - as soon as
you don’t use it for too large files, of course.

> Now that are the solution ? We could not increase tmpfs over 50% to
> 70% of physical ram without deadlock (OOM and so on). And it is not
> enought for your use. Should we use /var/tmp ? But it does not fit
> due to "Files and directories located in /var/tmp must not be deleted
> when the system is booted" (FHS). Whereas this kind of software want
> to be non persistant and tru file backed.
>
> Any suggestion is welcome

In all cases, do not assume /tmp was ever made for such a use case. You
need to locate your data somewhere else. Doing like gimp, which uses
$HOME but allows the user to specify something else, is a good way to
go.

--
.'`. Josselin Mouette
: :' :
`. `'
`-
 
Old 11-13-2011, 07:57 AM
Bastien ROUCARIES
 
Default /tmp as tmpfs and consequence for imaging software

On Sun, Nov 13, 2011 at 9:50 AM, Josselin Mouette <joss@debian.org> wrote:
> Le dimanche 13 novembre 2011 * 09:40 +0100, Bastien ROUCARIES a écrit :
>> No it is not true. Science and imaging software are better to use true
>> disk baked file. For instance, if I want ot invert a big matrix they
>> are pretty good algorithm that force only some part of the file to be
>> keep on disk. They known better than kernel when to put somepart on
>> the data on the slow disk.
>
> The application might know better its usage profile, but the kernel
> knows better how the actual hardware behaves. This is why there are now
> some APIs to give hints to the kernel instead of assume the application
> can deal with everything by itself.
>
>> And do not ask user to choose. Imageging software and movie maker
>> software have the same requirement than high performance science
>> software.
>
> Having to deal with quite a lot of HPC software, I can assure you that
> most of such applications do not know how to use disk or memory
> correctly. They see considerable speedup when using tmpfs - as soon as
> you don’t use it for too large files, of course.

Yes it the problem file bigger than memory.

>> Now that are the solution ? We could not increase tmpfs over 50% to
>> 70% of physical ram without deadlock (OOM and so on). And it is not
>> enought for your use. Should we use /var/tmp *? But it does not fit
>> due to "Files and directories located in /var/tmp must not be deleted
>> when the system is booted" (FHS). Whereas this kind of software want
>> to be non persistant and tru file backed.
>>
>> Any suggestion is welcome
>
> In all cases, do not assume /tmp was ever made for such a use case. You
> need to locate your data somewhere else. Doing like gimp, which uses
> $HOME but allows the user to specify something else, is a good way to
> go.

Ok could we made some policy about /tmp use ? Like do not create file
above 10M ? And fill RC bug if the apps do this ?

$HOME is not really nice but it could work. I have a tmp dir under my
home directry and some script to clean up at every log on.

Could we agree to mass report bug on this issue?

Bastien
> --
> *.'`. * * *Josselin Mouette
> : :' :
> `. `'
> *`-
>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CAE2SPAa20CaMtusxfn1p6xZ0P5FODn7y5jWH1cSAZ2tb7AJxN w@mail.gmail.com">http://lists.debian.org/CAE2SPAa20CaMtusxfn1p6xZ0P5FODn7y5jWH1cSAZ2tb7AJxN w@mail.gmail.com
 
Old 11-13-2011, 08:02 AM
Salvo Tomaselli
 
Default /tmp as tmpfs and consequence for imaging software

> I agree with samuel here. Science software know how to use disk baked
> file. And are better than general software. I will open rcbug to use
> /var/tmp instead of /tmp in this case. But it is a pitty.

/var/tmp has a little problem: is not cleared upon reboot.
In fact one time i couldn't do a graphical login anymore because the kde-stuff
in /var/tmp had taken the entire available space on the partitin.

Also i was thinking that if we consider the amount of IO that kde does on the
home of the user, and the amount that does on /var/tmp, and of course the many
libraries that it needs to load, and so on... In the end the activity on /tmp
compared to the activity in general is so small that i doubt keeping tmp on
the ram is going to have any positive impact at all on performances.

--
Salvo Tomaselli
 
Old 11-13-2011, 08:09 AM
Hendrik Sattler
 
Default /tmp as tmpfs and consequence for imaging software

Am Sonntag, 13. November 2011, 10:02:24 schrieb Salvo Tomaselli:
> > I agree with samuel here. Science software know how to use disk baked
> > file. And are better than general software. I will open rcbug to use
> > /var/tmp instead of /tmp in this case. But it is a pitty.
>
> /var/tmp has a little problem: is not cleared upon reboot.
> In fact one time i couldn't do a graphical login anymore because the
> kde-stuff in /var/tmp had taken the entire available space on the
> partitin.
>
> Also i was thinking that if we consider the amount of IO that kde does on
> the home of the user, and the amount that does on /var/tmp, and of course
> the many libraries that it needs to load, and so on... In the end the
> activity on /tmp compared to the activity in general is so small that i
> doubt keeping tmp on the ram is going to have any positive impact at all
> on performances.

Why must it be cleared on boot? What happens with this assumption if the user
does not reboot a very long time but only suspend/resume instead? Does your
software fail then?

Giving your program an option to specify the temp directory is the only real
solution. Hardcoding such a thing is a very lazy approach at best.
Additionally, add the feature to the program to clean stale files before the
next run (or to ask the user if it shall do that). This makes your reboot
assumption go away.

Your assumptions are bugs the software, not in the system.

HS


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201111131009.24021.post@hendrik-sattler.de">http://lists.debian.org/201111131009.24021.post@hendrik-sattler.de
 
Old 11-13-2011, 08:32 AM
Lars Wirzenius
 
Default /tmp as tmpfs and consequence for imaging software

On Sun, Nov 13, 2011 at 09:44:15AM +0100, Bastien ROUCARIES wrote:
> Yes I agree. But wich $TMPDIR should we use ? /var/tmp does not fit
> because it is not cleaned at boot. And the problem is the default have
> changed. I do not excuse sloppy programmer. but we need something like
> a standard tmp dir that is file backed and cleaned every boot.

You can, on the systems you administer, do one of the following:

* disable tmpfs for /tmp and arrange /tmp to have enough disk space
for all the things you run on your system; you can, for example,
mount a whole separate filesystem as /tmp, from a RAID-0 array
of several SSD drives, if you wish

* set TMPDIR to point at /var/tmp, or another filesystem,
either globally, or per user, or when starting particular
programs that need lots of temporary file space; you can, further,
arrange to have whatever directory that points at to be cleaned
at boot time; if you have the energy, you could even add a
configuration option to /etc/init.d/mountall-bootclean.sh to allow
the sysadmin to specify more directories to be cleaned at boot time,
rather than a hard-coded list (this would help others in your
situation in the future)

Either will solve your problem. Neither is a particularly good
default for Debian to have. This is one of those situations, it
seems to me, where there is no solution that satisfies everyone.

--
Freedom-based blog/wiki/web hosting: http://www.branchable.com/
 
Old 11-13-2011, 08:57 AM
Russell Coker
 
Default /tmp as tmpfs and consequence for imaging software

On Sun, 13 Nov 2011, Bastien ROUCARIES <roucaries.bastien@gmail.com> wrote:
> Ok could we made some policy about /tmp use ? Like do not create file
> above 10M ? And fill RC bug if the apps do this ?

10M is small by today's standards.

On Sun, 13 Nov 2011, Bastien ROUCARIES <roucaries.bastien@gmail.com> wrote:
> We could not increase tmpfs over 50% to
> 70% of physical ram without deadlock (OOM and so on).

Can you substantiate this claim about a deadlock? I've used a tmpfs that was
larger than physical RAM in the past without problems.

As for an OOM, that's just a matter of whether all the various uses of memory
exceed RAM+swap. For certain usage patterns more swap plus a large tmpfs work
well.

There was one time when I had to load a database from a dump file and it was
unreasonably slow. As the process was something I could repeat I put the
database on a tmpfs and then moved it to a regular filesystem after it
completed the load which saved hours.

On Sun, 13 Nov 2011, Carlos Alberto Lopez Perez <clopez@igalia.com> wrote:
> When the system is swapping heavily, if you are not using a preempt
> kernel the hole system will become so unresponsive while the swapping
> process is taking place that even your mouse pointer will stop moving.
> And Debian kernel is no preempt.

Ben has already described how the preemptive kernel patch doesn't affect this.

But there are many corner cases where disk IO performance can suffer. One
that hit me a few times recently was moving big files from a USB flash device
to an NFS server. When a workstation had a bunch of programs running that use
all RAM and a fair bit of swap the command "mv /mnt/usb/* /mnt/nfs" would
cause terrible performance even up to interfering with the mouse pointer.
Really it shouldn't cache the file that's being read (because it will be
unlinked) and it shouldn't cache the file that's being written because the NFS
server should be faster than the USB device (so no write caching) and because
it probably wouldn't make sense to cache for reading.

On Sun, 13 Nov 2011, Bastien ROUCARIES <roucaries.bastien@gmail.com> wrote:
> For instance using gscan2pdf on 60pages document create more than 1.2G
> of image file under /tmp and crash du to missing space.

I don't think that you can count on ANY filesystem having more than 1.2G of
free space on a random system. I run systems with less space than that on
/home and systems with less space on / . I think that sometimes the user just
needs to know what they are doing, if you do something that creates a big file
you need to ensure that there is enough space.

As an aside, I give some users their own filesystem under /home so that WHEN
(not if) they use up all available space they don't cause problems for other
people. No matter how much space you provide there are people who can waste
it all. I also occasionally give some users their own filesystem under /home
so that they will be unaffected by other users wasting space.

--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201111132057.25957.russell@coker.com.au">http://lists.debian.org/201111132057.25957.russell@coker.com.au
 
Old 11-13-2011, 09:30 AM
Thomas Goirand
 
Default /tmp as tmpfs and consequence for imaging software

On 11/13/2011 05:57 PM, Russell Coker wrote:
> On Sun, 13 Nov 2011, Bastien ROUCARIES <roucaries.bastien@gmail.com> wrote:
>
>> Ok could we made some policy about /tmp use ? Like do not create file
>> above 10M ? And fill RC bug if the apps do this ?
>>
> 10M is small by today's standards.
>
Agreed. Anyway, I'd be happy to have, by policy, some hard limits
We can discuss of a tolerable size, like 100M? Anyway, anything
bigger than 512 MB is obviously abusing /tmp, IMHO. But if we're
to have /tmp using tmpfs by default, it becomes really important
to have such policy.

For example, it happens that MySQL server fills up my /tmp (which
by the way, I put in a separate partition just because of that issue).
That'd be IMO a good candidate for an RC bug filling...

Thomas


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4EBF9C43.6080705@debian.org">http://lists.debian.org/4EBF9C43.6080705@debian.org
 

Thread Tools




All times are GMT. The time now is 07:30 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org