On 09/13/2012 03:54 AM, Pádraig Brady wrote:
> I'm going to err on the side of leaving sort(1) as is
> and using /tmp by default, as detailed at:
> http://lists.gnu.org/archive/html/coreutils/2012-09/msg00139.html
This is the perfect solution for all the people who
will switch /tmp back to disk im
On Thu, Sep 13, 2012 at 3:54 AM, Pádraig Brady wrote:
> One possible issue is that stale sort tmp files could persist
> in /var/tmp for 30 days even after a reboot.
>
> I'm going to err on the side of leaving sort(1) as is
> and using /tmp by default, as detailed at:
> http://lists.gnu.org/archive
On 05/31/2012 11:45 AM, Pádraig Brady wrote:
On 05/31/2012 08:14 AM, Roberto Ragusa wrote:
On 05/31/2012 02:40 AM, Lennart Poettering wrote:
Heya!
Please be aware that since the most recent systemd uploads /tmp is now
in tmpfs by default in Rawhide/F18.
[...]
This will most likely lead to a
Am 12.07.2012 21:54, schrieb Harald Hoyer:
> Again.. tmpfs is restricted to half the RAM size by default. You can't
> store 8-9GB of trash.. only 2GB, which might land on swap over time.
is it limited to half the RAM or 2 GB?
on my machine half the RAM is 8 GB
what about a application storing 4
On 07/13/2012 10:14 AM, Dennis Jacobfeuerborn wrote:
On 07/13/2012 09:14 AM, Roberto Ragusa wrote:
On 07/12/2012 09:54 PM, Harald Hoyer wrote:
Again.. tmpfs is restricted to half the RAM size by default. You can't
store 8-9GB of trash.. only 2GB, which might land on swap over time.
As I have
On 07/13/2012 09:14 AM, Roberto Ragusa wrote:
> On 07/12/2012 09:54 PM, Harald Hoyer wrote:
>
>> Again.. tmpfs is restricted to half the RAM size by default. You can't
>> store 8-9GB of trash.. only 2GB, which might land on swap over time.
>
> As I have already pointed out some time ago, isn't a
On 07/12/2012 09:54 PM, Harald Hoyer wrote:
> Again.. tmpfs is restricted to half the RAM size by default. You can't
> store 8-9GB of trash.. only 2GB, which might land on swap over time.
As I have already pointed out some time ago, isn't a bizarre situation
that as an application developer I can
On Thu, Jul 12, 2012 at 6:43 PM, David Sommerseth wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 01/06/12 19:42, Brian Wheeler wrote:
>>
>>
>> On 06/01/2012 12:21 PM, Lennart Poettering wrote:
>>> I think most of the noise in this flame thread is due to a
>>> misunderstanding how
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/06/12 19:42, Brian Wheeler wrote:
>
>
> On 06/01/2012 12:21 PM, Lennart Poettering wrote:
>> I think most of the noise in this flame thread is due to a
>> misunderstanding how modern memory management works and the
>> assumption that having an
On Thu, Jun 21, 2012 at 8:57 PM, Chris Adams wrote:
> Once upon a time, Bruno Wolff III said:
>> I had been testing /tmp on tmpfs, but turned it off because it was hiding
>> /tmp where httpd had dumped a lot of core files which I was having trouble
>> removing.
>> There is probably some tricky wa
Once upon a time, Bruno Wolff III said:
> I had been testing /tmp on tmpfs, but turned it off because it was hiding
> /tmp where httpd had dumped a lot of core files which I was having trouble
> removing.
> There is probably some tricky way to bind mount / and get at that
Yep, not even particu
On Thu, Jun 21, 2012 at 12:09:48 -0400,
DJ Delorie wrote:
Additionally, it's been turned on in rawhide.
Rawhide nightlies have been failing, though, so how do we test this?
Run rawhide. You can do this by installing F17 and yum upgrading to rawhide.
There is an issue with dracut not work
On Thu, Jun 21, 2012 at 11:09 AM, DJ Delorie wrote:
>
>> Additionally, it's been turned on in rawhide.
>
> Rawhide nightlies have been failing, though, so how do we test this?
. . .or anything else? Wait until it composes, and then test. Unfortunately.
-J
> --
> devel mailing list
> devel@lis
> Additionally, it's been turned on in rawhide.
Rawhide nightlies have been failing, though, so how do we test this?
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Thu, Jun 21, 2012 at 3:42 AM, Tomas Mraz wrote:
> On Wed, 2012-06-20 at 16:57 -0400, Brian Wheeler wrote:
>
>> I know that we've been told that this is a done deal and that everyone
>> should just get over it, but this is a feature that I think truly sucks
>> for a lot of reasons and there hasn
On Wed, 2012-06-20 at 16:57 -0400, Brian Wheeler wrote:
> I know that we've been told that this is a done deal and that everyone
> should just get over it, but this is a feature that I think truly sucks
> for a lot of reasons and there hasn't been any _actual_ benefits that
> have been proven f
On 06/20/2012 08:06 PM, Brian Wheeler wrote:
> So the default is that I can use 2G in /tmp regardless of how much swap is
> present if the system memory size is 4G? So the only way to get more /tmp is
> to either mess with the max% or buy more ram?
Let's say it in this way:
on a 4GB machine if
On Wed, Jun 20, 2012 at 4:57 PM, Brian Wheeler wrote:
> But in any case the I/O advantages have never been shown, despite multiple
> requests by myself and others.
I posted some example numbers earlier in this thread. e.g. make on an
already compiled firefox source was half the time on tmpfs com
On 06/20/2012 02:16 PM, Gregory Maxwell wrote:
On Wed, Jun 20, 2012 at 1:54 PM, Jef Spaleta wrote:
On Wed, Jun 20, 2012 at 9:41 AM, Gregory Maxwell wrote:
Tmpfs volumes have a size set as a mount option. The default is half
the physical ram (not physical ram plus swap). You can change the si
Am 20.06.2012 19:41, schrieb Gregory Maxwell:
> On Wed, Jun 20, 2012 at 1:25 PM, Jef Spaleta wrote:
>> As a sysadmin...for a multi-seat configuration in a home network
>> environment...do I really need to anticipate maximum large file tmp
>> usage in calculating my swap partition size for my mul
Am 20.06.2012 19:18, schrieb Gregory Maxwell:
> On Wed, Jun 20, 2012 at 12:57 PM, Reindl Harald
> wrote:
>> i bet now someone is coming up wth "he must not dump a 100 Gb file to /tmp"
>> this is the wrong perspective
>> the right one is "the system must not crash if someone does"
>
> Good thin
On Wed, Jun 20, 2012 at 1:54 PM, Jef Spaleta wrote:
> On Wed, Jun 20, 2012 at 9:41 AM, Gregory Maxwell wrote:
>> Tmpfs volumes have a size set as a mount option. The default is half
>> the physical ram (not physical ram plus swap). You can change the size
>> with a remount. When its full, its ful
Once upon a time, Reindl Harald said:
> it is simply a fact that drop a 100 or 200 Gb file into tmpfs
> will bring down each machine existing currently and in the next
No, it won't.
Also, the default partitioning scheme for the existing Fedora setup
(with /tmp on /) also won't support dupming a
On 06/20/2012 01:55 PM, Chris Adams wrote:
Once upon a time, Brian Wheeler said:
So, how does this scenario work?
* The machine has 4G of RAM,
* > 50% RAM is being used by actual software (firefox, eclipse, mail
client, etc), so the other < 50% is pagecache
* The machine has 4G of swap, none
On 20/06/12 18:55, Chris Adams wrote:
2G gets written and then -ENOSPC. 2G gets pushed to swap.
The default for tmpfs mounts is an fs that is sized to RAM/2.
What is the scenario,
where it's a KVM host and 3/4 physical ram is assigned to Guests?
--
Regards,
Frank
"Jack of all, fubars"
--
On 06/20/2012 01:41 PM, Gregory Maxwell wrote:
What happens when I have 2 users who are both downloading dvd iso
sized images into /tmp as well as other things going on. Remind me...
where does firefox by default cache in progress downloads for the
"Open in" facility. Isn't it down in tmp?
Once upon a time, Brian Wheeler said:
> So, how does this scenario work?
>
> * The machine has 4G of RAM,
> * > 50% RAM is being used by actual software (firefox, eclipse, mail
> client, etc), so the other < 50% is pagecache
> * The machine has 4G of swap, none of which is active.
>
> So then a
On Wed, Jun 20, 2012 at 9:41 AM, Gregory Maxwell wrote:
> Tmpfs volumes have a size set as a mount option. The default is half
> the physical ram (not physical ram plus swap). You can change the size
> with a remount. When its full, its full, like any other filesystem
Okay that was what I was mis
On Wed, Jun 20, 2012 at 1:25 PM, Jef Spaleta wrote:
> As a sysadmin...for a multi-seat configuration in a home network
> environment...do I really need to anticipate maximum large file tmp
> usage in calculating my swap partition size for my multi-user family?
> 8 gigs of ram... so to be safe I wa
So, how does this scenario work?
* The machine has 4G of RAM,
* > 50% RAM is being used by actual software (firefox, eclipse, mail
client, etc), so the other < 50% is pagecache
* The machine has 4G of swap, none of which is active.
So then a user drops a 8.5G DVD image into /tmp.
On a traditi
On Fri, Jun 1, 2012 at 7:05 AM, Gregory Maxwell wrote:
> Thats not true (and I've used tmpfs for tmp for years, so I'm speaking
> from experience)— tmpfs is backed by swap on demand. Just add the
> space that you would have used for /tmp to your swap.
I am _very_ concerned about large files in c
On Wed, Jun 20, 2012 at 12:57 PM, Reindl Harald wrote:
> i bet now someone is coming up wth "he must not dump a 100 Gb file to /tmp"
> this is the wrong perspective
> the right one is "the system must not crash if someone does"
Good thing it doesn't.
--
devel mailing list
devel@lists.fedoraproje
Am 20.06.2012 18:49, schrieb Ralf Corsepius:
>> Since you can look at it either way in that regard, it's completely
>> reasonable
>> to have the option that's best for most users as the default. As I see it,
>> that's to enable tmpfs for /tmp .
>
> Again: It is not reasonable, it's generally and
On 06/20/2012 05:45 PM, Peter Jones wrote:
On 06/20/2012 10:16 AM, Reindl Harald wrote:
Am 20.06.2012 16:11, schrieb Ralf Corsepius:
On 06/20/2012 03:35 PM, Chris Lumens wrote:
Again: I'm perfectly happy if it is rejected as a feature. I don't
really care either way. What I'd really hate to
> Since you can look at it either way in that regard, it's completely
> reasonable to have the option that's best for most users as the
> default. As I see it, that's to enable tmpfs for /tmp .
Given a choice between "works for everyone" and "works well for most,
but fails in obscure ways for som
On 06/20/2012 10:16 AM, Reindl Harald wrote:
Am 20.06.2012 16:11, schrieb Ralf Corsepius:
On 06/20/2012 03:35 PM, Chris Lumens wrote:
Again: I'm perfectly happy if it is rejected as a feature. I don't
really care either way. What I'd really hate to see is a checkbox in the
installer so we are
On Thu, 21.06.12 00:01, Joel Rees (joel.r...@gmail.com) wrote:
> If Puttering really went on vacation after dropping a bombshell like
My name is Poettering, not Puttering.
> community to do the grunt work on his Master's thesis on things that
My master's thesis? Nah, no thanks, already got a go
On Tue, Jun 5, 2012 at 12:28 AM, Olav Vitters wrote:
> On Mon, Jun 04, 2012 at 08:44:38AM -0500, Michael Cronenworth wrote:
>> Matthias Clasen wrote:
>> > Its not his ignorance - he's on vacation for the next two weeks...
>>
>> Brian replied to Lennart 7 minutes after Lennart's e-mail and mine was
Am 20.06.2012 16:11, schrieb Ralf Corsepius:
> On 06/20/2012 03:35 PM, Chris Lumens wrote:
>>> Again: I'm perfectly happy if it is rejected as a feature. I don't
>>> really care either way. What I'd really hate to see is a checkbox in the
>>> installer so we are compelled to test both variations.
On 06/20/2012 03:35 PM, Chris Lumens wrote:
Again: I'm perfectly happy if it is rejected as a feature. I don't
really care either way. What I'd really hate to see is a checkbox in the
installer so we are compelled to test both variations...
>
Yeah, I won't be adding any checkboxes to have peopl
> Again: I'm perfectly happy if it is rejected as a feature. I don't
> really care either way. What I'd really hate to see is a checkbox in the
> installer so we are compelled to test both variations...
Yeah, I won't be adding any checkboxes to have people pick their /tmp
style.
- Chris
--
devel
On Wed, 2012-06-20 at 04:53 +0200, Ralf Corsepius wrote:
> On 06/02/2012 03:44 AM, Adam Williamson wrote:
> > On Fri, 2012-06-01 at 15:57 -0400, DJ Delorie wrote:
> >>> it's a bad design to ask the end user about this kind of thing
> >>> during installation.
> >>
> >> IIRC, I suggested a checkbox i
On 06/02/2012 03:44 AM, Adam Williamson wrote:
On Fri, 2012-06-01 at 15:57 -0400, DJ Delorie wrote:
it's a bad design to ask the end user about this kind of thing
during installation.
IIRC, I suggested a checkbox in the disk partitioning page, where
we're already asking the user all sorts of q
Olav Vitters wrote:
> Expecting and more or less demanding a reply after calling someone
> ignorant... not nice behaviour.
My intentions were not to insult anyone and I am not seeking a reply to
my e-mail.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman
On Mon, Jun 04, 2012 at 08:44:38AM -0500, Michael Cronenworth wrote:
> Matthias Clasen wrote:
> > Its not his ignorance - he's on vacation for the next two weeks...
>
> Brian replied to Lennart 7 minutes after Lennart's e-mail and mine was
> an hour after that as a pretty good indication Lennart w
Am 04.06.2012 15:36, schrieb Matthias Clasen:
> On Fri, 2012-06-01 at 13:50 -0500, Michael Cronenworth wrote:
>> Brian Wheeler wrote:
>>>
>>> How is this change a win?
>>
>> Unfortunately, due to Lennart's ignorance (we're all ignorant of
>> something), he will consider your e-mail "flame-bait" a
Am 04.06.2012 12:50, schrieb Alexey I. Froloff:
> On Fri, Jun 01, 2012 at 02:20:02PM -0500, Michael Cronenworth wrote:
>> It, in fact, provides proof that this feature is searching for a
>> problem. Which applications require gigabytes per second throughput out
>> of /tmp?
> sort(1) and maybe moc
Matthias Clasen wrote:
> Its not his ignorance - he's on vacation for the next two weeks...
Brian replied to Lennart 7 minutes after Lennart's e-mail and mine was
an hour after that as a pretty good indication Lennart was not going to
reply. Unless the timing was coincidental of him packing his ba
On Fri, 2012-06-01 at 13:50 -0500, Michael Cronenworth wrote:
> Brian Wheeler wrote:
> >
> > How is this change a win?
>
> Unfortunately, due to Lennart's ignorance (we're all ignorant of
> something), he will consider your e-mail "flame-bait" and not reply.
Its not his ignorance - he's on vacat
On Fri, Jun 01, 2012 at 02:20:02PM -0500, Michael Cronenworth wrote:
> It, in fact, provides proof that this feature is searching for a
> problem. Which applications require gigabytes per second throughput out
> of /tmp?
sort(1) and maybe mock(1) ;-)
> (and your numbers for tmpfs would equal ext4
On Fri, 2012-06-01 at 15:57 -0400, DJ Delorie wrote:
> > it's a bad design to ask the end user about this kind of thing
> > during installation.
>
> IIRC, I suggested a checkbox in the disk partitioning page, where
> we're already asking the user all sorts of questions about the
> filesystem layou
Am 02.06.2012 00:24, schrieb Pádraig Brady:
> On 06/01/2012 08:56 PM, Reindl Harald wrote:
>> HERE AGAIN THE FULL QUTOE TO GET BACK CONTEXT!
>>
So I'll patch sort to default to /var/tmp rather than /tmp
>>> thank you for breaking setups of well thought virtual machines
>>> on expensive SAN st
On 06/01/2012 08:56 PM, Reindl Harald wrote:
>
>
> Am 01.06.2012 20:14, schrieb Simo Sorce:
>> On Fri, 2012-06-01 at 12:58 -0500, Chris Adams wrote:
>>> Once upon a time, Simo Sorce said:
On Fri, 2012-06-01 at 11:02 -0500, Chris Adams wrote:
> Once upon a time, Reindl Harald said:
Am 01.06.2012 23:48, schrieb Nathanael D. Noblet:
> On 06/01/2012 03:23 PM, Garrett Holmstrom wrote:
>> On Fri, Jun 1, 2012 at 1:44 PM, Gregory Maxwell wrote:
>>> On Fri, Jun 1, 2012 at 12:28 PM, Reindl Harald
>>> wrote:
* it is a valid workload that a application creates a 10 GB tempfile
On 06/01/2012 03:23 PM, Garrett Holmstrom wrote:
On Fri, Jun 1, 2012 at 1:44 PM, Gregory Maxwell wrote:
On Fri, Jun 1, 2012 at 12:28 PM, Reindl Harald wrote:
* it is a valid workload that a application creates a 10 GB tempfile
* ok, you say: use /var/tmp
* well, i say: my whole rootfs is only
Am 01.06.2012 23:23, schrieb Garrett Holmstrom:
> On Fri, Jun 1, 2012 at 1:44 PM, Gregory Maxwell wrote:
>> On Fri, Jun 1, 2012 at 12:28 PM, Reindl Harald
>> wrote:
>>> * it is a valid workload that a application creates a 10 GB tempfile
>>> * ok, you say: use /var/tmp
>>> * well, i say: my wh
On Fri, Jun 1, 2012 at 1:44 PM, Gregory Maxwell wrote:
> On Fri, Jun 1, 2012 at 12:28 PM, Reindl Harald wrote:
>> * it is a valid workload that a application creates a 10 GB tempfile
>> * ok, you say: use /var/tmp
>> * well, i say: my whole rootfs is only 4 GB and 2 Gb are used
>
> If your rootfs
On Fri, 2012-06-01 at 12:47 -0700, Adam Williamson wrote:
> On Fri, 2012-06-01 at 15:28 -0400, Simo Sorce wrote:
>
> > I think the question here is can someone please point to a page with
> > numbers that justify /tmp -> tmpfs be the default for the most common
> > cases ?
> > laptop / vm with lim
Am 01.06.2012 22:44, schrieb Gregory Maxwell:
> On Fri, Jun 1, 2012 at 12:32 PM, Reindl Harald wrote:
>> if they are on disk under /tmp they are cached only
>> as long page-cache or active RAM is not needed for
>> the workload and the memory can be released instead
>> WRITE it do disk with swapp
On Fri, Jun 1, 2012 at 12:32 PM, Reindl Harald wrote:
>> I'm sorry, I couldn't quite hear you— perhaps more all-caps would help? :-)
>>
>> The dogmatic 'swap is bad for performance' is justified only because
>> writing/reading a slow disk is bad for performance.
>
> and how does /tmp in RAm change
Am 01.06.2012 22:14, schrieb Chris Adams:
> Once upon a time, Reindl Harald said:
>> and that does also patch all applications back which starts
>> using /var/tmp like "sort" as default for their temp-files?
>
> I keep seeing sort as the primary example: how often are people sorting
> multi-gig
Am 01.06.2012 21:59, schrieb Chris Adams:
> Once upon a time, Simo Sorce said:
>> Ok, say I have installed my new laptop and discover that the new /tmp
>> arrangement is not good for me and I'd rather keep /tmp on disk, how do
>> you go about that ? (No I do not have any un-partitioned space lef
Am 01.06.2012 20:14, schrieb Simo Sorce:
> On Fri, 2012-06-01 at 12:58 -0500, Chris Adams wrote:
>> Once upon a time, Simo Sorce said:
>>> On Fri, 2012-06-01 at 11:02 -0500, Chris Adams wrote:
Once upon a time, Reindl Harald said:
> thank you for breaking setups of well thought virtual
Am 01.06.2012 18:26, schrieb Gregory Maxwell:
> On Fri, Jun 1, 2012 at 11:09 AM, Reindl Harald wrote:
>> well designed machines do NOT swap and have not alligend
>> swap at all - in the case of virtualization you MUST NOT
>> enforce swapping if you really like perofrmance
>
> I'm sorry, I could
Am 01.06.2012 18:21, schrieb Lennart Poettering:
> I think most of the noise in this flame thread is due to a
> misunderstanding how modern memory management works and the assumption
> that having an explicit size limit on /tmp was a bad thing, even though
> it actually is a good thing... In fact
Am 01.06.2012 18:02, schrieb Chris Adams:
> Once upon a time, Reindl Harald said:
>> thank you for breaking setups of well thought virtual machines
>> on expensive SAN storages with a as small as possible rootfs
>> with a own virtual disk for /tmp with new defaults
>
> If you are mounting a fil
Once upon a time, Reindl Harald said:
> and that does also patch all applications back which starts
> using /var/tmp like "sort" as default for their temp-files?
I keep seeing sort as the primary example: how often are people sorting
multi-gigabyte files? I've been running with either a separate
Once upon a time, Simo Sorce said:
> Ok, say I have installed my new laptop and discover that the new /tmp
> arrangement is not good for me and I'd rather keep /tmp on disk, how do
> you go about that ? (No I do not have any un-partitioned space left, and
> using the root file system is fine by me
> it's a bad design to ask the end user about this kind of thing
> during installation.
IIRC, I suggested a checkbox in the disk partitioning page, where
we're already asking the user all sorts of questions about the
filesystem layout and mount points (including putting /tmp on a
separate partiti
On Fri, 2012-06-01 at 15:28 -0400, Simo Sorce wrote:
> I think the question here is can someone please point to a page with
> numbers that justify /tmp -> tmpfs be the default for the most common
> cases ?
> laptop / vm with limited RAM.
No, that's the question in the main thread. This subthread
On Fri, 2012-06-01 at 23:00 +0400, Alexey I. Froloff wrote:
> On Fri, Jun 01, 2012 at 01:50:55PM -0500, Michael Cronenworth wrote:
> > Not a single person who has claimed a performance or semantic win for
> > this /tmp move has replied when asked for proof.
> $ time dd if=/dev/zero of=/tmp/file bs=
Gregory Maxwell wrote:
> I haven't bothered because I have no clue what you'll accept and I
> fully accept you to move the goalposts.
Fedora application usage.
> For example, I build firefox in /tmp which is on tmpfs for me because
> on mostly finished trees the make is about 40% faster than with
On Fri, 2012-06-01 at 11:56 -0700, Adam Williamson wrote:
> On Fri, 2012-06-01 at 14:46 -0400, DJ Delorie wrote:
>
> > IMHO *telling* the user how to manage /tmp is wrong, whichever side of
> > the argument you're on. *Asking* them how to manage it is the right
> > way. That was my point in that
On Fri, Jun 01, 2012 at 03:22:32PM -0400, Gregory Maxwell wrote:
> On Fri, Jun 1, 2012 at 2:50 PM, Michael Cronenworth wrote:
> > Not a single person who has claimed a performance or semantic win for
> > this /tmp move has replied when asked for proof.
>
> I haven't bothered because I have no clu
On 06/01/2012 03:00 PM, Alexey I. Froloff wrote:
On Fri, Jun 01, 2012 at 01:50:55PM -0500, Michael Cronenworth wrote:
Not a single person who has claimed a performance or semantic win for
this /tmp move has replied when asked for proof.
$ time dd if=/dev/zero of=/tmp/file bs=1M count=10240
1024
On Fri, Jun 1, 2012 at 2:50 PM, Michael Cronenworth wrote:
> Not a single person who has claimed a performance or semantic win for
> this /tmp move has replied when asked for proof.
I haven't bothered because I have no clue what you'll accept and I
fully accept you to move the goalposts.
For exa
Alexey I. Froloff wrote:
> $ time dd [snip]
> Does that counts as a proof?
It, in fact, provides proof that this feature is searching for a
problem. Which applications require gigabytes per second throughput out
of /tmp?
(and your numbers for tmpfs would equal ext4 once you started swapping)
--
On Fri, Jun 01, 2012 at 11:00:57PM +0400, Alexey I. Froloff wrote:
> On Fri, Jun 01, 2012 at 01:50:55PM -0500, Michael Cronenworth wrote:
> > Not a single person who has claimed a performance or semantic win for
> > this /tmp move has replied when asked for proof.
> $ time dd if=/dev/zero of=/tmp/f
On Fri, Jun 01, 2012 at 06:21:28PM +0200, Lennart Poettering wrote:
> ext3 otoh means must be on disk in the end, [...]
This is plainly not true. If you create a file and immediate delete
it, ext3 won't write the data to disk (metadata is slightly different,
but in any case very small).
What are
On Fri, Jun 1, 2012 at 2:46 PM, DJ Delorie wrote:
> *I* want /tmp on disk. I still don't want someone else telling me I
> have to do it that way.
You can still put tmp on a disk if you're the kind of advanced users
who knows better enough to override the defaults.
But there does have to be a de
On Fri, Jun 01, 2012 at 01:50:55PM -0500, Michael Cronenworth wrote:
> Not a single person who has claimed a performance or semantic win for
> this /tmp move has replied when asked for proof.
$ time dd if=/dev/zero of=/tmp/file bs=1M count=10240
10240+0 records in
10240+0 records out
107374
On Fri, 2012-06-01 at 14:46 -0400, DJ Delorie wrote:
> IMHO *telling* the user how to manage /tmp is wrong, whichever side of
> the argument you're on. *Asking* them how to manage it is the right
> way. That was my point in that mail.
>
> *I* want /tmp on disk. I still don't want someone else
Brian Wheeler wrote:
>
> How is this change a win?
Unfortunately, due to Lennart's ignorance (we're all ignorant of
something), he will consider your e-mail "flame-bait" and not reply.
Not a single person who has claimed a performance or semantic win for
this /tmp move has replied when asked for
> Your quoting removed the fact that I was responding a statement that
> ram was the "wrong place". I was simply extending the comment. If
> you're willing to say that ram is the wrong place for something then
> there is nothing user hostile to say tmp is too.
"Wrong" in general has been used he
On Fri, Jun 1, 2012 at 2:28 PM, DJ Delorie wrote:
>> If they really aren't transient then /tmp is the wrong place for them.
> I will categorically disagree with any argument of the "the user
> shouldn't be doing that" type. Software exists to serve the user, not
> the other way around.
Your quot
> If they really aren't transient then /tmp is the wrong place for them.
I will categorically disagree with any argument of the "the user
shouldn't be doing that" type. Software exists to serve the user, not
the other way around.
Besides, I often don't realize that a file isn't transient until
On Fri, 2012-06-01 at 12:58 -0500, Chris Adams wrote:
> Once upon a time, Simo Sorce said:
> > On Fri, 2012-06-01 at 11:02 -0500, Chris Adams wrote:
> > > Once upon a time, Reindl Harald said:
> > > > thank you for breaking setups of well thought virtual machines
> > > > on expensive SAN storages
Once upon a time, Simo Sorce said:
> On Fri, 2012-06-01 at 11:02 -0500, Chris Adams wrote:
> > Once upon a time, Reindl Harald said:
> > > thank you for breaking setups of well thought virtual machines
> > > on expensive SAN storages with a as small as possible rootfs
> > > with a own virtual dis
On 06/01/2012 12:21 PM, Lennart Poettering wrote:
I think most of the noise in this flame thread is due to a
misunderstanding how modern memory management works and the assumption
that having an explicit size limit on /tmp was a bad thing, even though
it actually is a good thing... In fact, we
On 06/01/2012 12:27 PM, DJ Delorie wrote:
>> The feature may be adopted/promoted on the basis of SSD writecycle
>> preservation,
> I'm about to put in an SSD boot disk, so I care about this argument,
> but I'm still not using tmpfs, for my reasons stated previously.
>
>> but tmpfs also offers consi
On Fri, Jun 1, 2012 at 12:27 PM, DJ Delorie wrote:
> This conclusion is NOT TRUE for me. I've checked it. /tmp on ext3 on
> my system does NOT incur any disk I/O until long after the process
> using it has finished, if at all, as long as the files are small and
> transient.
Glad to see you've t
> The feature may be adopted/promoted on the basis of SSD writecycle
> preservation,
I'm about to put in an SSD boot disk, so I care about this argument,
but I'm still not using tmpfs, for my reasons stated previously.
> but tmpfs also offers considerable performance improvements for
> workloads
2012/6/2 Gregory Maxwell :
> On Fri, Jun 1, 2012 at 11:09 AM, Reindl Harald wrote:
>> well designed machines do NOT swap and have not alligend
>> swap at all - in the case of virtualization you MUST NOT
>> enforce swapping if you really like perofrmance
>
> I'm sorry, I couldn't quite hear you— pe
On Fri, Jun 1, 2012 at 11:09 AM, Reindl Harald wrote:
> well designed machines do NOT swap and have not alligend
> swap at all - in the case of virtualization you MUST NOT
> enforce swapping if you really like perofrmance
I'm sorry, I couldn't quite hear you— perhaps more all-caps would help? :-)
On Fri, 01.06.12 16:19, Richard W.M. Jones (rjo...@redhat.com) wrote:
> On Fri, Jun 01, 2012 at 11:05:26AM -0400, Gregory Maxwell wrote:
> > On Fri, Jun 1, 2012 at 9:50 AM, Gerry Reno wrote:
> > > So everyone needs to go out and buy twice as much RAM so F18+ can run
> > > /tmp as tmpfs without c
On Fri, 2012-06-01 at 11:02 -0500, Chris Adams wrote:
> Once upon a time, Reindl Harald said:
> > thank you for breaking setups of well thought virtual machines
> > on expensive SAN storages with a as small as possible rootfs
> > with a own virtual disk for /tmp with new defaults
>
> If you are m
On Fri, Jun 01, 2012 at 11:44:12AM -0400, Gerry Reno wrote:
>
> Well, I don't have any workloads that are doing high-speed create/remove of
> file in /tmp.
>
> And I don't think most people have any of those types of workloads either.
I do, but ext4 handles my workload marvelously. For high-sp
Once upon a time, Reindl Harald said:
> thank you for breaking setups of well thought virtual machines
> on expensive SAN storages with a as small as possible rootfs
> with a own virtual disk for /tmp with new defaults
If you are mounting a filesystem on /tmp, it'll be in /etc/fstab and
still wor
Am 01.06.2012 17:44, schrieb Gerry Reno:
> Well, I don't have any workloads that are doing high-speed create/remove of
> file in /tmp.
> And I don't think most people have any of those types of workloads either.
>
> Wouldn't it make sense that people with those types of workloads could enable
Am 01.06.2012 17:35, schrieb Gregory Maxwell:
> The feature may be adopted/promoted on the basis of SSD writecycle
> preservation, but tmpfs also offers considerable performance
> improvements for workloads that create/remove files in /tmp at high
> speed— which is the reason that many people hav
1 - 100 of 132 matches
Mail list logo
