Josselin Mouette writes:
> Le jeudi 07 juin 2012 à 15:48 +0100, Ben Hutchings a écrit :
>> There's no need to be a dick about it.
>
> Because this discussion was all about not being a dick to begin with, of
> course.
>
> Remind me who, in absence of consensus, explained that if tmpfs was
> ena
Le jeudi 07 juin 2012 à 15:48 +0100, Ben Hutchings a écrit :
> There's no need to be a dick about it.
Because this discussion was all about not being a dick to begin with, of
course.
Remind me who, in absence of consensus, explained that if tmpfs was
enabled by default, he would forcefully make
On Thu, 2012-06-07 at 09:37 +0200, Josselin Mouette wrote:
> Le mercredi 06 juin 2012 à 19:56 -0400, Joey Hess a écrit :
> > A lot of people came down on the pro-tmpfs side in this thread. You have
> > some good reasons to want to make it available to users. I just wanted
> > to invite you to make
Le mercredi 06 juin 2012 à 19:56 -0400, Joey Hess a écrit :
> A lot of people came down on the pro-tmpfs side in this thread. You have
> some good reasons to want to make it available to users. I just wanted
> to invite you to make it easier for users to enable tmpfs where
> appropriate -- d-i's p
So RAMTMP now defaults to off. I know it can be hard to give ground on
something you've invested a lot of work into, so Roger Leigh has my
respect for taking this thread into consideration.
A lot of people came down on the pro-tmpfs side in this thread. You have
some good reasons to want to make i
Goswin von Brederlow wrote:
> Uoti Urpala writes:
> > I haven't read the relevant kernel code, but that doesn't match the
> > behavior I see. Reading a large file from tmpfs and then allocating
> > memory results in large swap writes every time, even if the newly
> > allocated memory is not itself
Uoti Urpala writes:
> Goswin von Brederlow wrote:
>> > 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 th
Salvo Tomaselli writes:
>> No, tmpfs will be swapped out if you don't use a file for a while but
>> something else uses memory, including IO caching.
> unless too many things want to use memory, then tmpfs gives a great
> contribution in taking down the machine.
>
> As you pointed out yourself
Ben Hutchings writes:
> On Fri, Jun 01, 2012 at 11:19:40PM +0200, Carlos Alberto Lopez Perez wrote:
>> On 01/06/12 13:33, Goswin von Brederlow wrote:
>> >> > I don't know the ultimate reason behind this ugly behaviour of Linux
>> >> > when the swapping process is happening, but I know this is rea
Salvo Tomaselli writes:
>> If anyone wants to experience that then write out some GB of data over
>> NFS. After a short while processes will hang while others keep running.
>
> True, that's what i was saying.
> But if there is not enough memory, it's not only one process that will hang.
> It's e
Roger Leigh wrote:
> OK, some benchmarks were requested in this thread in a few places.
No, a lack of premature optimisation was requested.
When one is engaged in premature optimisation, one does lots of
benchmarks, and finds things that seem to speed up nicely, and
has many happy nice numbers .
Hi
Now lets do a benchmark on a busy system (during a kernel compile) and
some memory pressure, due to building on tmpfs. While this is not
directly representative for /tmp/ usage patterns, it does show what
happens if /tmp/ gets full and fights against normal RAM uses.
Tested on a current uns
> that problem applies to disks as well, and especially to small /
> partitions, if you don't have /tmp somewhere else.
But by default the installer doesn't create a small / partition, it uses all
the available space.
So by default just by clicking next->next, there are no such problems.
Users wh
* Toni Mueller [2012-06-02 13:46:19 +0200] wrote:
> My suggested fix for this problem is to install a ~/tmp upon account
> creation, and set the TEMP environment variable in, say,
> /etc/environments. That *should* fix up all cases except for rogue
> applications that don't honour $TEMP. We can th
Hi Thomas,
On Sat, Jun 02, 2012 at 07:33:26PM +0800, Thomas Goirand wrote:
> > All the complaints about /tmp as tmpfs come down to one simple issue:
> > The size of the tmpfs isn't chosen well. It would be more constructive
> > to find a better heuristic for the size there.
>
> No. The complain i
On 06/01/2012 06:50 PM, Goswin von Brederlow wrote:
> There is also no problem with having large files in tmpfs. Only
> requirement is that you make tmpfs large enough and add enough ram
> and/or swap to cope with it.
Well, there's the problem that it will take some memory at least. So
either your
2012/6/2 Carlos Alberto Lopez Perez wrote:
> IMHO The logical way of behaving in such situation is to slow-down the
> IO bandwidth of the processes that are filling the cache, by sending to
> sleep any process that requests more IO while the cache is full instead
> of trying to free RAM by swappin
2012/6/2 Roger Leigh wrote:
> These tests were all performed on current unstable using a core2 quad
> core system with ext4 and swap on LVM on a 1 TiB MD RAID1 PV, and
> Btrfs internally using RAID1 over 2 1TiB partitions.
Well, not fair for btrfs, but anyway, finally, some tests! Thank you
for d
On Fri, Jun 01, 2012 at 11:19:40PM +0200, Carlos Alberto Lopez Perez wrote:
> On 01/06/12 13:33, Goswin von Brederlow wrote:
> >> > I don't know the ultimate reason behind this ugly behaviour of Linux
> >> > when the swapping process is happening, but I know this is real and it
> >> > happens becau
On Fri, May 25, 2012 at 02:22:24AM +0300, 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 faster when they're written on rea
On 01/06/12 13:33, Goswin von Brederlow wrote:
>> > I don't know the ultimate reason behind this ugly behaviour of Linux
>> > when the swapping process is happening, but I know this is real and it
>> > happens because I have experimented this situation myself more than a
>> > couple of times.
> It'
Goswin von Brederlow wrote:
> > 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 a
2012/6/1 Roger Leigh wrote:
> I'm certainly not averse to switching the default back, if this is the
> best solution at the present time for the majority of our users.
If only it was the best solution...
> As was seen in both this an earlier discussions, there is not a clear-cut
> consensus here
> And you are not correct here. The tmpfs defaults to guaranteeing
> a certain fixed size being available, as I stated above. If the
> memory was used up by applications and data, then the system will
> swap, drop cached data, flush unwritten data to disc etc. in order
> to make room for it. Yo
> No, tmpfs will be swapped out if you don't use a file for a while but
> something else uses memory, including IO caching.
unless too many things want to use memory, then tmpfs gives a great
contribution in taking down the machine.
As you pointed out yourself in another email, under memory pr
> If anyone wants to experience that then write out some GB of data over
> NFS. After a short while processes will hang while others keep running.
True, that's what i was saying.
But if there is not enough memory, it's not only one process that will hang.
It's everything.
So i think that adding p
On Fri, May 25, 2012 at 12:44:03PM +0100, Roger Leigh wrote:
> 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 part
On Mon, May 28, 2012 at 01:21:43PM +0800, Thomas Goirand wrote:
> On 05/28/2012 05:32 AM, Roger Leigh wrote:
> > On Sun, May 27, 2012 at 10:46:27PM +0800, Thomas Goirand wrote:
> >> On 05/25/2012 07:44 PM, Roger Leigh wrote:
> >>> However, the majority of
> >>> software which finds the tmpfs too sm
Josselin Mouette writes:
> 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
Salvo Tomaselli writes:
>> 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.
>
Carlos Alberto Lopez Perez writes:
> On 25/05/12 12:20, Henrique de Moraes Holschuh wrote:
>> 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
Salvo Tomaselli writes:
>> 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.
Wrong. The threa
Vincent Danjean writes:
> 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
Nikolaus Rath writes:
> 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
Carlos Alberto Lopez Perez writes:
> On 25/05/12 12:14, Henrique de Moraes Holschuh wrote:
>> 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 fil
Henrique de Moraes Holschuh writes:
> 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.
On Wed, May 30, 2012 at 02:48:26PM +0200, Bjørn Mork wrote:
> Vincent Lefevre writes:
> > On 2012-05-30 12:08:29 +0200, Josselin Mouette wrote:
> >> Le samedi 26 mai 2012 à 23:02 +0200, Carlos Alberto Lopez Perez a
> >> écrit :
> >> > With "tmpfs on /tmp" you are breaking many applications that a
On Wed, May 30, 2012 at 02:48:26PM +0200, Bjørn Mork wrote:
> Does that make any difference at all? If an application is unable to
> handle the out-of-space condition, then it will be unable to handle the
> out-of-space condition no matter how big the file system is. Increasing
> the file system
Vincent Lefevre writes:
> On 2012-05-30 12:08:29 +0200, Josselin Mouette wrote:
>> Le samedi 26 mai 2012 à 23:02 +0200, Carlos Alberto Lopez Perez a
>> écrit :
>> > With "tmpfs on /tmp" you are breaking many applications that assume that
>> > they have enough space to write on /tmp like the flash
On 2012-05-30 12:08:29 +0200, Josselin Mouette wrote:
> Le samedi 26 mai 2012 à 23:02 +0200, Carlos Alberto Lopez Perez a
> écrit :
> > With "tmpfs on /tmp" you are breaking many applications that assume that
> > they have enough space to write on /tmp like the flash player ( see
> > Debian bug #6
Le samedi 26 mai 2012 à 23:02 +0200, Carlos Alberto Lopez Perez a
écrit :
> With "tmpfs on /tmp" you are breaking many applications that assume that
> they have enough space to write on /tmp like the flash player ( see
> Debian bug #666096 ) or cdrecord software ( see #665634 ).
Seriously, this i
On Mon, May 28, 2012 at 08:26:52AM -0400, Weldon Goree wrote:
> at some point). Much better developers than me seem to have formed
> this opinion too (cf browsers' behavior while it waits for you to tell
> it what to do with an unknown content-type: it's a disk-based pipe to
> whatever program you
On Mon, May 28, 2012 at 01:21:43PM +0800, Thomas Goirand wrote:
As you wrote, nothing is infinite. I don't think that /tmp is worse than
/home like other said. Your /home could become full as well.
Your /home could be a network share like NFS and /tmp a local partition,
so you don’t want to us
On Mon, 28 May 2012 13:03:47 +0200
Toni Mueller wrote:
> It's not, see below. Also, most of the time, /tmp goes into / (on
> smaller systems), and is thus typically *very* much limited in space.
If the theory is to design for the "trained chicken" install (and it still is,
right?), then / gets t
Hi,
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 memory renders the whole process of writing the file useless.
> If the fil
On 05/28/2012 05:32 AM, Roger Leigh wrote:
> On Sun, May 27, 2012 at 10:46:27PM +0800, Thomas Goirand wrote:
>> On 05/25/2012 07:44 PM, Roger Leigh wrote:
>>> However, the majority of
>>> software which finds the tmpfs too small has unreasonable expectations
>>> of what can be expected to be availa
On Sun, May 27, 2012 at 10:01:22PM +0200, Tollef Fog Heen wrote:
> ]] Thomas Goirand
>
> > Come on, WE CAN! Let's create a /run/tmp *now*, it wont cost us much,
> > then later applications can slowly use it if they want. Worst case:
> > not a lot of app uses it, and the /run/tmp tmpfs isn't used
On Sun, May 27, 2012 at 10:46:27PM +0800, Thomas Goirand wrote:
> On 05/25/2012 07:44 PM, Roger Leigh wrote:
> > However, the majority of
> > software which finds the tmpfs too small has unreasonable expectations
> > of what can be expected to be available (by default).
> >
> We welcome you to r
On Sat, May 26, 2012 at 04:39:34PM -0400, Joey Hess wrote:
> Roger Leigh wrote:
> > I did want to have this for wheezy (#633299). But I lacked the time
> > and familiarity with the d-i code, and the d-i developers also have
> > higher priorities.
>
> Personally, this d-i developer has as one prio
2012/5/27 Adam Borowski wrote:
> First, you're benchmarking the speed of process creation, not of file
> operations. Starting up seq or mv takes ages compared to an in-memory
> file write.
They may be slower than in-memory operations, but they're definitely
faster than fsync(). So if there was f
]] Thomas Goirand
> Come on, WE CAN! Let's create a /run/tmp *now*, it wont cost us much,
> then later applications can slowly use it if they want. Worst case:
> not a lot of app uses it, and the /run/tmp tmpfs isn't used much,
> which isn't a problem. Best case: everyone that needs a fast space
On 05/28/2012 02:08 AM, Salvo Tomaselli wrote:
> man 3 mktemp
>
I was talking about /bin/mktemp.
Thomas
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fc28113.20
Salvo Tomaselli dixit:
>> Please define who are the people you are talking about. If they aren't
>> using mktemp, please file a bug.
>
>man 3 mktemp
>BUGS
> Never use mktemp() [...]
Your manpage search order is (also) wrong:
‣ https://www.mirbsd.org/man.cgi?mktemp
(1) come before (3) secti
> Please define who are the people you are talking about. If they aren't
> using mktemp, please file a bug.
man 3 mktemp
BUGS
Never use mktemp() [...]
--
Salvo Tomaselli
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contac
On 05/26/2012 03:12 AM, Nikolaus Rath wrote:
> Aren't quotas only for non-root and per file system? I think we're
> already safe from non-root filling up / because of the reserved 5%.
>
> Best,
>
>-Nikolaus
>
That's a bit off-topic but...
XFS has project quota, which are directory based. I'd
On 05/25/2012 07:44 PM, Roger Leigh wrote:
> However, the majority of
> software which finds the tmpfs too small has unreasonable expectations
> of what can be expected to be available (by default).
>
We welcome you to rewrite / patch these software then!
Good luck, the list is huge, and growing
On 27/05/12 14:53, Thomas Goirand wrote:
> On 05/25/2012 03:29 PM, Josselin Mouette wrote:
>> Which means a *huge* performance
>> improvement. Do the measurements yourself, it works with basically
>> anything that makes heavy use of /tmp.
>>
> I have yet to know what application you are talking
On 05/25/2012 03:29 PM, Josselin Mouette wrote:
> Which means a *huge* performance
> improvement. Do the measurements yourself, it works with basically
> anything that makes heavy use of /tmp.
>
I have yet to know what application you are talking about.
Who's doing heavy use of /tmp exactly?
Th
On 05/25/2012 05:41 PM, Josselin Mouette wrote:
> 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 pagin
On 05/27/2012 08:09 PM, Henrique de Moraes Holschuh wrote:
> But my point was that people will not switch to writing small temporary
> files somewhere else, because they have not switched to writing files to
> $TMPDIR even after 10 years.
>
Please define who are the people you are talking about.
On 05/27/2012 04:32 AM, Russ Allbery wrote:
> In an ideal world, in which we could throw out all of UNIX history and
> make up our own rules, 1 (alone) would be /var/tmp, 2 would be some new
> path (/run/tmp or something), and 3 would be /tmp. But we don't live in
> the world where it's likely we
On 05/27/2012 04:32 AM, Russ Allbery wrote:
> The root problem here is that we have multiple parameters that we want to
> set on temporary storage:
>
> 1. Space for dumping arbitrary files without assuming anything about the
>structure of the user's home directory.
>
> 2. Fast space for small t
On Sat, 26 May 2012, Carlos Alberto Lopez Perez wrote:
> So please, don't argue about theoretical things about virtual memory or
> IO schedulers. If you are a desktop Linux user, you should know how ugly
> the things get when the system is swapping.
Mine is not that annoying, but certainly not bec
On Sat, 26 May 2012, Joey Hess wrote:
> Henrique de Moraes Holschuh wrote:
> > In fact it is the other way. We have /var/tmp for the large file since
> > about forever, and important platforms that have /tmp in memory since the
> > early 2000's (Solaris)
> >
> > And that STILL wasn't enough f
On Sun, May 27, 2012 at 05:21:04AM +0300, Serge wrote:
> 2012/5/27 Adam Borowski wrote:
>
> > I think that box had jfs, but other filesystems are no different: for
> > example, ext* will fsync() during a rename() call behind your back even
> > if you don't request it, forcing every file to hit the
On Sat, May 26, 2012 at 10:59:06PM -0400, Joey Hess wrote:
> Adam Borowski wrote:
> > I think that box had jfs, but other filesystems are no different: for
> > example, ext* will fsync() during a rename() call behind your back even if
> > you don't request it, forcing every file to hit the disk pla
Adam Borowski wrote:
> I think that box had jfs, but other filesystems are no different: for
> example, ext* will fsync() during a rename() call behind your back even if
> you don't request it, forcing every file to hit the disk platters even
> though they'll immediately get changed again. For fil
2012/5/27 Adam Borowski wrote:
> I think that box had jfs, but other filesystems are no different: for
> example, ext* will fsync() during a rename() call behind your back even
> if you don't request it, forcing every file to hit the disk
This is easy to check:
$ cd /path/to/tmpfs
$ touch 1
On Sat, May 26, 2012 at 04:27:01PM -0400, Joey Hess wrote:
> Josselin Mouette wrote:
> > Oh stop, there is a difference: in a tmpfs the system doesn’t need to
> > commit the data on disk, and therefore can write it to disk whenever it
> > likes, especially when the disk is not too used. There is no
On Sat, 2012-05-26 at 16:29 -0400, Joey Hess wrote:
> Ted Ts'o wrote:
> > The main advantage of tmpfs is that it gets wiped on reboot, and so it
> > prevents people and applications from thinking that they can keep
> > stuff in /tmp forever. It's also faster because a file system has to
> > do ext
On 25/05/12 12:14, Henrique de Moraes Holschuh wrote:
> 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 orde
Roger Leigh wrote:
> I did want to have this for wheezy (#633299). But I lacked the time
> and familiarity with the d-i code, and the d-i developers also have
> higher priorities.
Personally, this d-i developer has as one priority that the system d-i
installs be broadly useful. d-i has at times n
Joey Hess writes:
> Henrique de Moraes Holschuh wrote:
>> In fact it is the other way. We have /var/tmp for the large file since
>> about forever, and important platforms that have /tmp in memory since
>> the early 2000's (Solaris)
>> And that STILL wasn't enough for people to not screw it
Ted Ts'o wrote:
> The main advantage of tmpfs is that it gets wiped on reboot, and so it
> prevents people and applications from thinking that they can keep
> stuff in /tmp forever. It's also faster because a file system has to
> do extra work to make sure the files are preserved after a reboot.
Josselin Mouette wrote:
> Oh stop, there is a difference: in a tmpfs the system doesn’t need to
> commit the data on disk, and therefore can write it to disk whenever it
> likes, especially when the disk is not too used. There is no need to
> keep a journal nor to access the disk several times to u
Henrique de Moraes Holschuh wrote:
> In fact it is the other way. We have /var/tmp for the large file since
> about forever, and important platforms that have /tmp in memory since the
> early 2000's (Solaris)
>
> And that STILL wasn't enough for people to not screw it up and dump large
> file
On 25/05/12 12:20, Henrique de Moraes Holschuh wrote:
> 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 t
On Fri, 25 May 2012 15:12:03 -0400
Nikolaus Rath wrote:
> Weldon Goree writes:
> > If only ext*fs supported quotas...
>
> Aren't quotas only for non-root and per file system? I think we're
> already safe from non-root filling up / because of the reserved 5%.
Yes, but I was thinking of a multi-
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
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
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
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
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
> 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 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
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
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
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
1 - 100 of 139 matches
Mail list logo
