2012/6/5 Goswin von Brederlow wrote:
> You keep claiming tmpfs compromises system stability. Can you show a
> kernel oops of a crash caused by tmpfs?
No crashes, system just becomes slow and hard/impossible to use. See the
Stefan Lippers-Hollmann email about tmpfs vs disk writes. System that
does
Serge writes:
> 2012/6/1 Goswin von Brederlow wrote:
>
>> All the complaints about /tmp as tmpfs come down to one simple issue:
>> The size of the tmpfs isn't chosen well.
>
> Mounting /tmp to tmpfs not just breaks a lot of apps and reduces system
> stability, but it actually does nothing else. Y
Mike Hommey writes:
> On Tue, Jun 05, 2012 at 09:29:46AM +0300, Serge wrote:
>> 2012/6/1 Goswin von Brederlow wrote:
>>
>> > All the complaints about /tmp as tmpfs come down to one simple issue:
>> > The size of the tmpfs isn't chosen well.
>>
>> Mounting /tmp to tmpfs not just breaks a lot of
On Tue, Jun 05, 2012 at 09:29:46AM +0300, Serge wrote:
> 2012/6/1 Goswin von Brederlow wrote:
>
> > All the complaints about /tmp as tmpfs come down to one simple issue:
> > The size of the tmpfs isn't chosen well.
>
> Mounting /tmp to tmpfs not just breaks a lot of apps and reduces system
> stab
2012/6/1 Goswin von Brederlow wrote:
> All the complaints about /tmp as tmpfs come down to one simple issue:
> The size of the tmpfs isn't chosen well.
Mounting /tmp to tmpfs not just breaks a lot of apps and reduces system
stability, but it actually does nothing else. You get no benefits from
/t
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?
gcc, ocamlopt, mc, lintian
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsu
On Thu, May 31, 2012 at 12:46:49AM +0300, Uoti Urpala wrote:
Also, nowadays normal filesystems are journaled; using a journal for
writes to /tmp damages the SSD for zero benefit.
Writing to /tmp will damage a SSD? Are you serious? And writing to /var
or /home will not?
If SSDs are so easy da
2012/5/31 Uoti Urpala wrote:
>> you eat cache memory. Meaning, you store /tmp files in cache even when
>> they're not used, so kernel cannot use that memory to store some useful
>> files. This increases I/O and makes the system slower.
>
> The tmpfs files will be written to swap if they aren't acc
Serge wrote:
> you eat cache memory. Meaning, you store /tmp files in cache even when
> they're not used, so kernel cannot use that memory to store some useful
> files. This increases I/O and makes the system slower.
The tmpfs files will be written to swap if they aren't accessed much and
the kern
2012/5/30 Vincent Lefevre 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 pushed to disk;
>>
>> That's not at all the same, the page ca
On 2012-05-25 14:49:14 +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 pushed to d
On 26 May 2012 19:20, Carlos Alberto Lopez Perez wrote:
> *Important*: use "df -h /tmp" NOT "du -hs /tmp", since the flash player
> deletes the file entry from /tmp as soon as it gets the inode allocated.
> I believe this a measure to "prevent" piracy (people ripping the video
> from /tmp)
I thin
On 28/05/12 08:15, Miles Bader wrote:
> Salvo Tomaselli writes:
>>> This is indeed a valid point. But that’s no regression; /tmp has
>>> always been for small short-lived files, and /var/tmp for those
>>> that are not one of them or not both.
>>
>> You just made up this difference.
>
> No he didn
Salvo Tomaselli writes:
>> This is indeed a valid point. But that’s no regression; /tmp has
>> always been for small short-lived files, and /var/tmp for those
>> that are not one of them or not both.
>
> You just made up this difference.
No he didn't, it's common practice from unix-days-of-yore (
On 27/05/12 20:01, Thorsten Glaser wrote:
> This is indeed a valid point. But that’s no regression; /tmp has
> always been for small short-lived files, and /var/tmp for those
> that are not one of them or not both.
I am still waiting for someone to tell me where is said that /tmp should
be for sma
> This is indeed a valid point. But that’s no regression; /tmp has
> always been for small short-lived files, and /var/tmp for those
> that are not one of them or not both.
You just made up this difference.
Nothing nowhere says anything about the size of the files. The only thing
mentioned is th
Joey Hess dixit:
>If programs that write large files to /tmp are changed to usr /var/tmp,
>then over time a system will accumulate orphaned large tmp files in
>/var/tmp. Nothing will come along and clean them up.
This is indeed a valid point. But that’s no regression; /tmp has
always been for sma
On 05/27/2012 02:35 AM, François Bottin wrote:
> My point is that I can't stand that the major point to not use tmpfs
> is caused by a closed source software. If you think it is faulty, then
> do not use it!
> By the way, I can't reproduce your problem. That's probably due to the
> fact that there
On 05/27/2012 02:55 AM, Mike Hommey wrote:
> I hope it isn't, because it's poor "security". It's easy to read the
> file from /proc/$pid/fd/$num
>
> Mike
>
If you were to trust Adobe in terms of security, then you'd be the first
person I know to do so.
Jokes set apart, I believe that they just
Ted Ts'o wrote:
> If you're worried about installations which don't have much memory
> (i.e., the 512mb netbook), then swap is absolutely mandatory, I would
> think!
Not really. I have no legitimate programs that use more than 50% of my 1 gb.
I have an SSD. So why enable swap? If chromium goes cr
On Sat, May 26, 2012 at 08:20:46PM +0200, Carlos Alberto Lopez Perez wrote:
> On 26/05/12 19:43, Russ Allbery wrote:
> > Carlos Alberto Lopez Perez writes:
> >> On 26/05/12 19:13, Russ Allbery wrote:
> >
> >>> I find some of the assertions in this thread confusing. I've been
> >>> using tmpfs /t
On 05/26/2012 07:08 PM, Thomas Goirand wrote:
On 05/26/2012 11:14 PM, François Bottin wrote:
On 05/26/2012 04:47 PM, Thomas Goirand wrote:
Try playing a 2h video with flash, and see that 60 MB isn't enough...
If Adobe Flash is broken, then fix it!
I will let you ask the sources from Adobe,
Carlos Alberto Lopez Perez writes:
> On 26/05/12 19:43, Russ Allbery wrote:
>> Carlos Alberto Lopez Perez writes:
>>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666096
>> That bug contains little actual information, not even what software was
>> being used.
> Ok... so you want a prove?
On 26/05/12 19:43, Russ Allbery wrote:
> Carlos Alberto Lopez Perez writes:
>> On 26/05/12 19:13, Russ Allbery wrote:
>
>>> I find some of the assertions in this thread confusing. I've been
>>> using tmpfs /tmp on my laptop for quite some time and have watched
>>> hour-long movies via the Adobe
Carlos Alberto Lopez Perez writes:
> On 26/05/12 19:13, Russ Allbery wrote:
>> I find some of the assertions in this thread confusing. I've been
>> using tmpfs /tmp on my laptop for quite some time and have watched
>> hour-long movies via the Adobe Flash player and have never noticed any
>> unex
On 26/05/12 19:13, Russ Allbery wrote:
> Thomas Goirand writes:
>
>> I will let you ask the sources from Adobe, create an alternative *that
>> works*. I will also let you fix all the other apps that we mentioned
>> that have the same kind of issues. But *IN THE MEAN WHILE*, until you
>> are done
Thomas Goirand writes:
> I will let you ask the sources from Adobe, create an alternative *that
> works*. I will also let you fix all the other apps that we mentioned
> that have the same kind of issues. But *IN THE MEAN WHILE*, until you
> are done with this huge and important work, let's not ch
On 05/26/2012 11:14 PM, François Bottin wrote:
> On 05/26/2012 04:47 PM, Thomas Goirand wrote:
>> Try playing a 2h video with flash, and see that 60 MB isn't enough...
>
> If Adobe Flash is broken, then fix it!
>
>
I will let you ask the sources from Adobe, create an
alternative *that works*. I wil
On 05/26/2012 04:47 PM, Thomas Goirand wrote:
Try playing a 2h video with flash, and see that 60 MB isn't enough...
If Adobe Flash is broken, then fix it!
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debia
On 05/26/2012 01:33 PM, Clint Byrum wrote:
> On laptops and other power sensitive devices, this is pretty critical.
>
> Hypothetical: I have 2GB of RAM, and I want to watch a 50MB video file
> on a connection that will take, say, 10 minutes to cache the whole thing
> (and its a 10 minute video).
>
On Sat, May 26, 2012 at 10:47:37PM +0800, Thomas Goirand 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? :/
>
On 05/26/2012 04:40 PM, Andrey Rahmatullin wrote:
> On Sat, May 26, 2012 at 03:24:02AM +0800, Thomas Goirand wrote:
>
>>> /tmp 8,0G 60M 8,0G1% /tmp
>>> Does this count as "large files"?
>>> As "a lot of small-only files"?
>>>
>>>
>> Exactly how is th
2012/5/26 Clint Byrum:
> On laptops and other power sensitive devices, this is pretty critical.
> Hypothetical: I have 2GB of RAM, and I want to watch a 50MB video file
> on a connection that will take, say, 10 minutes to cache the whole thing
> (and its a 10 minute video).
> With a regular file
On Fri, 25 May 2012 21:56:55 -0400
Ted Ts'o wrote:
>
> The major difference is that tmpfs pages only get written out to swap
> when the system is under memory pressure. In contrast, pages which
> are backed by a filesystem will start being written to disk after 30
> seconds _or_ if the system i
On Sat, May 26, 2012 at 03:24:02AM +0800, Thomas Goirand 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 *
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 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
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 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
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
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
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
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
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
50 matches
Mail list logo
