On 05/25/2012 10:03 PM, Philip Ashmore wrote:
> Hi there.
>
> First, here's what I'm talking about -
> http://en.wikipedia.org/wiki/Permalink
> Unfortunately Wikipedia doesn't offer permalinks itself, so
> hopefully the above link won't "rot".
And here's the permalink to the above article, as it
On 05/26/2012 09:20 AM, Nikolaus Rath wrote:
> I believe tmpfs memory is swapped out preferentially, so your scenario
> doesn't have to play out like that. However, paging being a complex
> process, it's not impossible either.
I haven't read the actual kernel code, just making assumption
from what
Excerpts from Ted Ts'o's message of 2012-05-25 18:56:55 -0700:
> On Fri, May 25, 2012 at 02:49:14PM +0100, Will Daniels wrote:
> > On 25/05/12 13:52, Ted Ts'o wrote:
> > >So what? If you write to a normal file system, it goes into the page
> > >cache, which is pretty much the same as writing into
2012/5/26 Miles Bader wrote:
>> I'm asking for *popular* apps, that create files in /tmp, *never put
>> large files* there, and become *noticeably* faster with /tmp on tmpfs?
> Is that even the issue, for the most part? My impression is that
> using tmpfs is just logistically simpler and safer -
On 26/05/12 04:34, Russ Allbery wrote:
> Philip Ashmore writes:
>
>> Here's where I wish I was a shell script guru:
>>for var in `cat set.txt`; do
>> { if in env discard }
>>done
>>{ sort offenders by decending size }
>> Here's a summary of the ones that caught my eye. Sorry if
Philip Ashmore writes:
> Here's where I wish I was a shell script guru:
>for var in `cat set.txt`; do
> { if in env discard }
>done
>{ sort offenders by decending size }
> Here's a summary of the ones that caught my eye. Sorry if I missed
> anyone out!
Oh. This is smelling l
Hi,
On Fri, May 25, 2012 at 08:14:28PM -0700, Russ Allbery wrote:
> Philip Ashmore writes:
> I'm curious why even your set of shell variables is so large, though. My
> environment is only 1699 bytes on a system I logged onto via ssh, and 1998
> on my desktop (running Xfce). One of the biggest c
On 26/05/12 04:14, Russ Allbery wrote:
> I'm curious why even your set of shell variables is so large, though. My
> environment is only 1699 bytes on a system I logged onto via ssh, and
1998
> on my desktop (running Xfce). One of the biggest chunks of that is
> LS_COLORS.
>
Here's where I wish
Philip Ashmore writes:
> According to "man sh" (which links to the dash man page)
> set [{ -options | +options | -- }] arg ...
> The set command performs three different functions.
> With no arguments, it lists the values of all shell variables.
> So are these copi
On 26/05/12 03:59, Philip Ashmore wrote:
> On 26/05/12 03:50, Philip Ashmore wrote:
>>
>> That's 225517 bytes that needs to be copied every time a script runs.
>
> Yeah that should read "every time a script or program runs."
>
> Philip
>
Sorry Ben, our emails collided.
According to "man sh" (whic
On 26/05/12 03:50, Philip Ashmore wrote:
That's 225517 bytes that needs to be copied every time a script runs.
Yeah that should read "every time a script or program runs."
Philip
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Cont
On Sat, May 26, 2012 at 03:50:02AM +0100, Philip Ashmore wrote:
[...]
> On my machine running "set > set.txt && ls -lsa set.txt" reveals that my
> environment contains 225517 of "stuff" - some of it is even being
> taken up by
> exported function definitions!
>
> That's 225517 bytes that needs to
Hi there.
I recently had cause to search for an environment variable to see if it
was being set.
As a result I noticed that the environment has become a bit of a dumping
ground for
installed programs where configuration files would have been a cleaner
option.
Looking for an override in the e
2012/5/25 Nikolaus Rath wrote:
> I don't think /tmp as part of the rootfs is a good idea for the reasons
> outlined in the rest of my mail.
Forgot to answer that part. Sorry.
> I think having / and /tmp share the same file system is a bad idea,
> because then writing lots of stuff to /tmp would
Hi there.
First, here's what I'm talking about -
http://en.wikipedia.org/wiki/Permalink
Unfortunately Wikipedia doesn't offer permalinks itself, so hopefully
the above
link won't "rot".
This was initially in reference to the recent spat of comments/opinions to
"Re: Moving /tmp to tmpfs makes
Thomas Goirand writes:
> On 05/25/2012 05:33 PM, Mehdi Dogguy wrote:
>>> What if we're installing Debian on a very small system, and that we
>>> need operations with big files in /tmp?
>>>
>>
>> Increase your swap?
>
> So, in this case, we will have the following scenario:
> - An app writes in /t
On Fri, May 25, 2012 at 02:49:14PM +0100, Will Daniels wrote:
> On 25/05/12 13:52, Ted Ts'o wrote:
> >So what? If you write to a normal file system, it goes into the page
> >cache, which is pretty much the same as writing into tmpfs. In both
> >cases if you have swap configured, the data will get
Serge writes:
> I'm asking for *popular* apps, that create files in /tmp, *never put
> large files* there, and become *noticeably* faster with /tmp on tmpfs?
Is that even the issue, for the most part? My impression is that
using tmpfs is just logistically simpler and safer -- it can be
mounted v
2012/5/25 Thorsten Glaser wrote:
Ok, we have guesses, let's do some TESTS...
>> Can you name some popular real-world program that write
>> only small files and become noticeably faster when /tmp is on tmpfs?
> Most shell scripts using << (here documents). mc, out of all things,
> as long as the
Le Fri, May 25, 2012 at 12:44:03PM +0100, Roger Leigh a écrit :
>
> I haven't got anything particularly new to add to the discussion here.
> But I would like to refer you to the previous discussion on the
> topic. I am well aware that the default does not satisfy all use
> cases, but that's simpl
Serge writes:
>> Every tool either supports setting TMPDIR=/var/tmp before running
>> it or is buggy. Go fix these instead
>
> Do I understand you right? You suggest every tool that need large
> tmp files to use /var/tmp instead?
That's not a new suggestion, it's been standard practice for nigh-
On Fri, May 25, 2012 at 08:14:10PM +0300, Serge wrote:
> 2012/5/25 Neil Williams wrote:
> > Different hardware -> different software selection.
>
> I don't understand your point. I could understand it if we were choosing
> among benefits that most users get from /tmp being on disk and /tmp being
>
Nikolaus Rath wrote:
>I think having / and /tmp share the same file system is a bad idea,
>because then writing lots of stuff to /tmp would potentially fill up
>the
>root file system (that typically also includes /var) and then cause a
>lot of breakage.
no, by default ext3/4 reserves 5% of the d
Weldon Goree writes:
> On Fri, 2012-05-25 at 10:02 -0400, Nikolaus Rath wrote:
>> I think having / and /tmp share the same file system is a bad idea,
>> because then writing lots of stuff to /tmp would potentially fill up the
>> root file system (that typically also includes /var) and then cause a
In data Friday 25 May 2012 21:23:28, Thorsten Glaser ha scritto:
> Salvo Tomaselli dixit:
> >tmpfs will make it stay forever in the RAM, caches are flushed to disk and
> >their space can be used for new things.
>
> For sane values of “forever”, usually a second of so.
I've things in my /tmp that w
Le 25/05/2012 04:00, Steve Langasek a écrit :
> On Fri, May 25, 2012 at 03:57:28AM +0300, Serge wrote:
>>> Every file that exists in /tmp on the system from which I'm writing this
>>> exists there not because the application is saving memory but because the
>>> application needs to share that file
On 05/25/2012 05:33 PM, Mehdi Dogguy wrote:
>> What if we're installing Debian on a very small system, and that we
>> need operations with big files in /tmp?
>>
>
> Increase your swap?
So, in this case, we will have the following scenario:
- An app writes in /tmp
- There's not enough space, so th
Salvo Tomaselli dixit:
>tmpfs will make it stay forever in the RAM, caches are flushed to disk and
>their space can be used for new things.
For sane values of “forever”, usually a second of so.
As long as there’s a way to change it¹, please don’t optimise
for the uncommon behaviour.
① tmpfs ca
On 05/26/2012 12:21 AM, Thorsten Glaser wrote:
> What you want is
> to optimise for a corner case.
>
Ah... So Mysql, flash videos, mc, image editors,
cd burners, and all the (very common) examples
he gave are just "corner cases" in your book?
We must have very different readings...
Thomas
--
On 05/25/2012 10:20 PM, Andrey Rahmatullin wrote:
> /tmp 8,0G 60M 8,0G1% /tmp
> Does this count as "large files"?
> As "a lot of small-only files"?
>
Exactly how is this a practical explanation and example? :/
Are you saying that in *your case* /tmp is almost
> So what? If you write to a normal file system, it goes into the page
> cache, which is pretty much the same as writing into tmpfs.
tmpfs will make it stay forever in the RAM, caches are flushed to disk and
their space can be used for new things.
- Ted
--
Salv
Serge writes:
> 2012/5/25 Nikolaus Rath wrote:
>
>> You still haven't said what the new default should be.
>
> The suggestion was to just leave it as it was configured in partitioner.
> If it was configured as a part of root fs leave it as it is. If it's on
> a separate partition leave it there. J
On Fri, 2012-05-25 at 10:02 -0400, Nikolaus Rath wrote:
> I think having / and /tmp share the same file system is a bad idea,
> because then writing lots of stuff to /tmp would potentially fill up the
> root file system (that typically also includes /var) and then cause a
> lot of breakage.
If onl
2012/5/25 Neil Williams wrote:
> Do you not use swap?
I use it for suspend-to-disk.
> Yes you lose functionality but functionality takes up resources, so
> something has to give.
Which functionality will I lose by placing /tmp on the real disk?
> The vast majority of systems have large amounts
2012/5/25 Nikolaus Rath wrote:
> You still haven't said what the new default should be.
The suggestion was to just leave it as it was configured in partitioner.
If it was configured as a part of root fs leave it as it is. If it's on
a separate partition leave it there. Just no automatic tmpfs.
I
Serge dixit:
>cases. Can you name some popular real-world program that write
>only small files and become noticeably faster when /tmp is on tmpfs?
Most shell scripts using << (here documents). mc, out of all things,
as long as the temporary files (e.g. of a tarball) fit inside it.
And countless
2012/5/25 Jon Dowland wrote:
>> I wasn't able to watch a web presentation (from something like
>> vimeo/youtube), because there was not enough free space in /tmp for
>> flash player to download and show it.
>
> I thought those were streaming video sites?
You mean, those sites don't store temporar
> > Switch to the deadline IO scheduler
> > [...] and make proper use of cgroups.
> > [...] And disable memory overcommit
[Serge]
> instead of fixing a single default option you suggest every debian
> user to tweak and/or rebuild the kernel? Are you serious? ;)
What?!? "and/or rebuild the kerne
On Fri, 25 May 2012 15:25:58 +0300
Serge wrote:
> 2012/5/25 Neil Williams wrote:
>
> > You cannot expect to mix those two worlds and for things to "just
> > work".
>
> Easy. Let's leave /tmp on a real disk and both world will "just work".
Do you not use swap?
> > If program A is too resource
Serge writes:
> Suggestion
> ==
> Do not mount /tmp as tmpfs by default. Instead...
> Debian already allows custom partitioning during the system install. For
> example it's possible to mount /tmp on a separate partition. The suggestion
> is to extend partitioner with a new option "Configu
]] Josselin Mouette
> Le vendredi 25 mai 2012 à 11:11 +0200, Salvo Tomaselli a écrit:
> > You seem to forget that memory is not an unlimited resource, the
> > system might need it for other things, and in that case a large
> > tmpfs causes severe slowdown (and even complete freeze).
>
> Then inc
On Fri, May 25, 2012 at 05:08:42PM +0800, Thomas Goirand wrote:
> On 05/25/2012 03:22 PM, Jon Dowland wrote:
> > How much RAM do you have / how big is your /tmp(fs)? The fact this caused
> > you trouble suggests to me that they must be very small.
> >
> What if we're installing Debian on a very
On Fri, May 25, 2012 at 11:44:15AM +, Thorsten Glaser wrote:
> No. An application might not know it’s writing to tmpfs (for
> example, if it wasn’t even written for an operating system
> with tmpfs in the first place). And it might want to use sync
> writes. The user of such application might w
On Fri, May 25, 2012 at 05:08:37PM +0300, Serge wrote:
> > Why do you assume tmpfs contents is always written to the swap?
>
> Most programs, using /tmp for temporary files, may write *large* files
> there. So most programs fill tmpfs with large files. So tmpfs grows and
> swaps out (probably swap
2012/5/25 Andrey Rahmatullin wrote:
> Why do you assume tmpfs contents is always written to the swap?
Most programs, using /tmp for temporary files, may write *large* files
there. So most programs fill tmpfs with large files. So tmpfs grows and
swaps out (probably swapping out other applications
On 25/05/12 13:50, Serge wrote:
Again, I'm not asking to drop this feature. I'm asking to have it disabled
*by default* but supported by debian installer, so really smart people,
that know what may be broken by it, but really need it, could enable it.
+1
On 25/05/12 13:52, Ted Ts'o wrote:
So
Le vendredi 25 mai 2012 à 16:01 +0300, Uoti Urpala a écrit :
> There is one significant difference though. When you read data back to
> memory from swap, the kernel does not remember that it already exists on
> disk; when the data is evicted from memory again, it is unnecessarily
> rewritten to di
Josselin Mouette wrote:
> Files which are written on a regular filesystem stay on memory. This is
> called the buffer cache. Whenever they are not used and/or the system
> needs to reclaim memory, they are trashed.
> Files which are written on a tmpfs stay on memory. Whenever they are not
> used an
> ow...@bugs.debian.org is the place to report this.
>
> Thanks,
>
I just send the mail there, thanks for that info.
Kind regards,
Michael
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
On Fri, May 25, 2012 at 03:50:31PM +0300, Serge wrote:
> /tmp on tmpfs won't help in that case. You do not reduce number of disk
> writes, you just move them to other directories. As you suggested, all
> the programs will still use files i.e. in /var/tmp. Or they'll write to
> swap if tmpfs is larg
Hi,
On 2012-05-25 13:40, Michael Stummvoll wrote:
Hi there,
this Bugreport (see below) seems to break the bts [1]
just for the record.
ow...@bugs.debian.org is the place to report this.
Thanks,
--
Jonathan Wiltshire j...@debian.org
Debian Developer
On Fri, May 25, 2012 at 11:11:06AM +0200, Salvo Tomaselli wrote:
> > Files which are written on a regular filesystem stay on memory. This is
> > called the buffer cache. Whenever they are not used and/or the system
> > needs to reclaim memory, they are trashed.
> > Files which are written on a tmpf
2012/5/25 Thorsten Glaser wrote:
> It’s faster because the files don’t even get written to disc if
> they’re kept for, say, five minutes, and aren’t just short-lived.
Theoretically, yes. But I'm not asking to forbid everybody to use
tmpfs. We're talking about defaults and about the most used test
Hi there,
this Bugreport (see below) seems to break the bts [1]
just for the record.
kind regards,
Michael
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674515
Beginn der weitergeleiteten Nachricht:
Datum: Fri, 25 May 2012 0
2012/5/25 Henrique de Moraes Holschuh wrote:
> Switch to the deadline IO scheduler
> [...] and make proper use of cgroups.
> [...] And disable memory overcommit
Ehm, so you assume that heavy swapping is not a bad thing, and instead of
fixing a single default option you suggest every debian user t
2012/5/25 Neil Williams wrote:
> You cannot expect to mix those two worlds and for things to "just
> work".
Easy. Let's leave /tmp on a real disk and both world will "just work".
> If program A is too resource-hungry, find (or write) program B.
Or fix the program A, right? And here we go... By
Chow Loong Jin dixit:
>On 25/05/2012 18:20, Salvo Tomaselli wrote:
>> Double-click on a .tar causes it to be unpacked in /tmp/something.
>> I suppose a lot of not so skilled users do that instead of tar -xf
>
>That doesn't seem to happen with file-roller. Perhaps you need to file a bug
Hm. mc doe
Jon Dowland dixit:
>On Fri, May 25, 2012 at 09:46:37AM +0200, Vincent Danjean wrote:
>> If some kind of sync is required by the application, I think this is
>> because the application want to ensure the data are really written to
>> the disk so that their state remains coherent even in case of cra
On Fri, May 25, 2012 at 02:22:24AM +0300, Serge wrote:
> I've read across different debates about whether using tmpfs is good or bad
> but I could not find the most important reason, so here it is...
I haven't got anything particularly new to add to the discussion here.
But I would like to refer y
On Fri, May 25, 2012 at 1:32 AM, Brian May
wrote:
> On 23 May 2012 23:31, Bastien ROUCARIES wrote:
>> 9. git checkout -b debian-patches/6.7.7.0-1
>> 10. git checkout -b debian/6.7.7.0-1 # create new debian branch
>
> Just curious here, why do you create a new branch for every Debian
> revision?
Henrique de Moraes Holschuh dixit:
>On Fri, 25 May 2012, Thomas Goirand wrote:
>> for small files, and in that case, it's faster. In reality, it's
>> not that much faster, thanks to Linux caching of the filesystem,
>
>Under heavy filesystem IO load, yes it is. By several orders of magnitude.
Not
On 25/05/2012 18:20, Salvo Tomaselli wrote:
> Double-click on a .tar causes it to be unpacked in /tmp/something.
> I suppose a lot of not so skilled users do that instead of tar -xf
That doesn't seem to happen with file-roller. Perhaps you need to file a bug
with your graphical archiver program.
On Fri, 25 May 2012, Salvo Tomaselli wrote:
> nevertheless. And somehow the OOM killer was not even triggered, i kept
> ending
> up with a system where i had a working shell but could not run certain
> commands (such as kill), but i could see the output of "free" for example.
Switch to the dead
On Fri, 25 May 2012, Salvo Tomaselli wrote:
> > Because paging out a couple Gigabytes is veery different from
> > writing a couple Gigabytes to disk, of course.
>
> Yes because writing that on disk will only block the thread performing the
> write, not every thread that tries to allocate memo
> Doing that on inferior hardware is just plain stupid. If you have
> plenty of
> disk space, just unpack the tar archive.
Double-click on a .tar causes it to be unpacked in /tmp/something.
I suppose a lot of not so skilled users do that instead of tar -xf
> And those with lots of RAM but not so
On Fri, 25 May 2012, Jon Dowland wrote:
> On Fri, May 25, 2012 at 09:46:37AM +0200, Vincent Danjean wrote:
> > If some kind of sync is required by the application, I think this is
> > because the application want to ensure the data are really written to
> > the disk so that their state remains cohe
On Friday 25 May 2012 09:46:37 Vincent Danjean wrote:
> If some kind of sync is required by the application, I think this is
> because the application want to ensure the data are really written to
> the disk so that their state remains coherent even in case of crash.
> If the application is ok to
On Fri, 25 May 2012, Thomas Goirand wrote:
> for small files, and in that case, it's faster. In reality, it's
> not that much faster, thanks to Linux caching of the filesystem,
Under heavy filesystem IO load, yes it is. By several orders of magnitude.
> the point. Maybe we should add a /small-fi
In data Friday 25 May 2012 11:39:07, Josselin Mouette ha scritto:
> Le vendredi 25 mai 2012 à 11:11 +0200, Salvo Tomaselli a écrit :
> > You seem to forget that memory is not an unlimited resource, the system
> > might need it for other things, and in that case a large tmpfs causes
> > severe slowd
Am 2012-05-25 11:19, schrieb Salvo Tomaselli:
It's beginning to sound like your particular machines need either
more
RAM or to use a different temporary location which is on a permanent
location. Just add some rules to clean it all up at reboot.
Perhaps there are a couple of thousand users with
> Because paging out a couple Gigabytes is veery different from
> writing a couple Gigabytes to disk, of course.
Yes because writing that on disk will only block the thread performing the
write, not every thread that tries to allocate memory.
--
Salvo Tomaselli
--
To UNSUBSCRIBE, email t
Le vendredi 25 mai 2012 à 11:04 +0200, Salvo Tomaselli a écrit :
> Apparently not everybody has experienced that, and this would explain why
> they
> are so happy about the idea of paging out a couple of Gigabytes.
Because paging out a couple Gigabytes is veery different from
writing a coup
Le vendredi 25 mai 2012 à 11:11 +0200, Salvo Tomaselli a écrit :
> You seem to forget that memory is not an unlimited resource, the system might
> need it for other things, and in that case a large tmpfs causes severe
> slowdown (and even complete freeze).
Then increase your swap size.
When yo
On 25/05/12 11:08, Thomas Goirand wrote:
On 05/25/2012 03:22 PM, Jon Dowland wrote:
How much RAM do you have / how big is your /tmp(fs)? The fact this
caused you trouble suggests to me that they must be very small.
What if we're installing Debian on a very small system, and that we
need operat
Hi all,
like many, I also felt like I had something to say in that thread. But as
discussed in the “making debian-devel useful” thread(s), I will wait a bit to
see if others will not say it better before me.
Most importantly, it has been proposed many times that pepole limit themselves
to roughl
On Vi, 25 mai 12, 17:08:42, Thomas Goirand wrote:
> On 05/25/2012 03:22 PM, Jon Dowland wrote:
> > How much RAM do you have / how big is your /tmp(fs)? The fact this caused
> > you trouble suggests to me that they must be very small.
> >
> What if we're installing Debian on a very small system,
> It's beginning to sound like your particular machines need either more
> RAM or to use a different temporary location which is on a permanent
> location. Just add some rules to clean it all up at reboot.
Perhaps there are a couple of thousand users with the same use case, I don't
know if it is t
> This is complete bullshit. If you know nothing about how virtual memory
> works, please refrain from making a fool of yourself.
:-(
> Files which are written on a regular filesystem stay on memory. This is
> called the buffer cache. Whenever they are not used and/or the system
> needs to recla
> We all know how bad can Linux behave in some conditions involving heavy
> swap usage.
Apparently not everybody has experienced that, and this would explain why they
are so happy about the idea of paging out a couple of Gigabytes.
--
Salvo Tomaselli
--
To UNSUBSCRIBE, email to debian-devel-
On 05/25/2012 03:22 PM, Jon Dowland wrote:
> How much RAM do you have / how big is your /tmp(fs)? The fact this caused
> you trouble suggests to me that they must be very small.
>
What if we're installing Debian on a very small system, and that
we need operations with big files in /tmp?
How muc
On Fri, May 25, 2012 at 09:46:37AM +0200, Vincent Danjean wrote:
> If some kind of sync is required by the application, I think this is
> because the application want to ensure the data are really written to
> the disk so that their state remains coherent even in case of crash.
> If the applicati
On Fri, 25 May 2012 02:22:24 +0300
Serge wrote:
> What's a temporary file? Really, why would applications temporarily store
> its data in a file? They do that to *free some memory*. Placing those files
> back to memory renders the whole process of writing the file useless.
Most of the time when
On Fri, May 25, 2012 at 08:22:20AM +0100, Jon Dowland wrote:
> > > What's a temporary file? Really, why would applications temporarily store
> > > its data in a file? They do that to *free some memory*. Placing those
> > > files
> > > back to memory renders the whole process of writing the file us
Le 25/05/2012 05:03, Russell Coker a écrit :
> On Fri, 25 May 2012, Serge wrote:
>> Q: /tmp on tmpfs increases apps performance.
>> A: What apps? Real apps don't write files during performance-critical
>>operations. Even if they do, they write large files. And large files are
>>written fas
Le vendredi 25 mai 2012 à 02:22 +0300, Serge a écrit :
> I've read across different debates about whether using tmpfs is good or bad
> but I could not find the most important reason, so here it is...
>
> Reason
> ==
> What's a temporary file? Really, why would applications temporarily store
>
On Fri, May 25, 2012 at 12:41:44PM +0600, Andrey Rahmatullin wrote:
> On Fri, May 25, 2012 at 02:22:24AM +0300, Serge wrote:
> > What's a temporary file? Really, why would applications temporarily store
> > its data in a file? They do that to *free some memory*. Placing those files
> > back to memo
On Fri, May 25, 2012 at 06:08:34AM +0300, Serge wrote:
> It dosn't always work in practice. Among the problems I faced myself...
> I wasn't able to watch a web presentation (from something like
> vimeo/youtube), because there was not enough free space in /tmp for flash
> player to download and show
87 matches
Mail list logo
