On Tue, Apr 10, 2012 at 07:36:39PM +0200, drago01 wrote:
> On Tue, Apr 10, 2012 at 3:31 PM, Michael Cronenworth wrote:
> > Richard W.M. Jones wrote:
> >> tmpfs is different in a number of important ways:
> >>
> >> - it's very limited in space compared to a real disk
> >
> > Adobe Flash uses /tmp
On Tue, Apr 10, 2012 at 3:31 PM, Michael Cronenworth wrote:
> Richard W.M. Jones wrote:
>> tmpfs is different in a number of important ways:
>>
>> - it's very limited in space compared to a real disk
>
> Adobe Flash uses /tmp to store video stream data.
s/uses/used to/ ... it stopped doing that
Richard W.M. Jones wrote:
> tmpfs is different in a number of important ways:
>
> - it's very limited in space compared to a real disk
Adobe Flash uses /tmp to store video stream data. How are distributions
who have implemented this handling large (say movie) Flash video
streams? I could easily
Reindl Harald wrote:
> Am 06.04.2012 14:58, schrieb Ralf Corsepius:
>>> Brasero, k3b and
>>> applications for scanning will probably need patches.
>>
>> No idea, what you are intending to do. These apps use huge amounts of
>> temporary data. Amounts of data, its devs probably considered to be too
On Apr 6, 2012, at 1:02 PM, Brian Wheeler wrote:
> On 04/06/2012 02:50 PM, Chris Murphy wrote:
>> What happens to /tmp on tmpfs when real memory and swap are completely
>> consumed?
>
> I assume it would get an -ENOSPC...but with RAM and swap being full I don't
> expect that the end user would
On 04/06/2012 02:50 PM, Chris Murphy wrote:
What happens to /tmp on tmpfs when real memory and swap are completely
consumed?
I assume it would get an -ENOSPC...but with RAM and swap being full I
don't expect that the end user would ever see the error before the
machine bogged down to the po
Am 06.04.2012 20:50, schrieb Chris Murphy:
>
> On Apr 6, 2012, at 8:03 AM, Vratislav Podzimek wrote:
That a lost fight, because one of /tmp's primary purposes is to
>>> temporarily store almost arbitrarily huge amounts of data, instead of
>>> storing them in memory.
>> This is the key ove
On Apr 6, 2012, at 8:20 AM, Michael Cronenworth wrote:
> I'm really not worried about IO or SSD life from /tmp usage.
I think the premise behind the coddling of SSD shouldn't be a consideration. If
if true, it won't be true much longer. Are the advocates of SSD coddling
suggesting we disable
On Apr 6, 2012, at 8:03 AM, Vratislav Podzimek wrote:
>>> That a lost fight, because one of /tmp's primary purposes is to
>> temporarily store almost arbitrarily huge amounts of data, instead of
>> storing them in memory.
> This is the key overlooked fact.
What happens to /tmp on tmpfs when rea
Hi.
On Fri, 06 Apr 2012 09:41:08 -0500, Michael Cronenworth wrote
> So I need to invest a week or two setting up blktraces across multiple
> application loads and come back with a series of graphs and charts to
> show how little IO is done in /tmp?
As I said, I think you're right in general wrt
Am 06.04.2012 16:38, schrieb Ralf Ertzinger:
> Hi.
>
> On Fri, 06 Apr 2012 09:20:46 -0500, Michael Cronenworth wrote
>
>> I have numbers to *dispute* these claims.
>>
>> (server with Apache, koji, LDAP)$ sudo du -sh /tmp
>> 396K /tmp
>>
>> (work desktop)$ sudo du -sh /tmp
>> 352K /tmp
>>
>> (se
Am 06.04.2012 14:58, schrieb Ralf Corsepius:
>> Brasero, k3b and
>> applications for scanning will probably need patches.
>
> No idea, what you are intending to do. These apps use huge amounts of
> temporary data. Amounts of data, its devs
> probably considered to be too big to be stored in mem
Ralf Ertzinger wrote:
> I see what you're trying to say, and I tend to agree with you, but
> the amount of space consumed at any one point in time does not reflect
> the amount of IO going on on that file system.
So I need to invest a week or two setting up blktraces across multiple
application lo
Hi.
On Fri, 06 Apr 2012 09:20:46 -0500, Michael Cronenworth wrote
> I have numbers to *dispute* these claims.
>
> (server with Apache, koji, LDAP)$ sudo du -sh /tmp
> 396K /tmp
>
> (work desktop)$ sudo du -sh /tmp
> 352K /tmp
>
> (server with Apache, bugzilla, wiki)$ sudo du -sh /tmp
> 312K
Jaroslav Skarvada wrote:
> Any numbers to support these claims?
I have numbers to *dispute* these claims.
(server with Apache, koji, LDAP)$ sudo du -sh /tmp
396K/tmp
(work desktop)$ sudo du -sh /tmp
352K/tmp
(server with Apache, bugzilla, wiki)$ sudo du -sh /tmp
312K/tmp
(home desk
On Fri, 2012-04-06 at 14:58 +0200, Ralf Corsepius wrote:
> On 04/06/2012 01:47 PM, Marcela Mašláňová wrote:
> > On 04/06/2012 11:14 AM, Vratislav Podzimek wrote:
> >> On Mon, 2012-04-02 at 20:58 +0100, Richard W.M. Jones wrote:
> >>> On Mon, Apr 02, 2012 at 08:32:56PM +0200, Miloslav Trmač wrote:
>
> The wiki page says:
>By implementing this we, by default, generate less IO on disks.
>This
>increases SSD lifetime, saves a bit of power and makes things a
>bit
>faster.
>
Any numbers to support these claims?
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.
On 04/06/2012 02:58 PM, Ralf Corsepius wrote:
On 04/06/2012 01:47 PM, Marcela Mašláňová wrote:
On 04/06/2012 11:14 AM, Vratislav Podzimek wrote:
On Mon, 2012-04-02 at 20:58 +0100, Richard W.M. Jones wrote:
On Mon, Apr 02, 2012 at 08:32:56PM +0200, Miloslav Trmač wrote:
* #834 F18 Feature: /tm
On 04/06/2012 07:47 AM, Marcela Mašláňová wrote:
On 04/06/2012 11:14 AM, Vratislav Podzimek wrote:
On Mon, 2012-04-02 at 20:58 +0100, Richard W.M. Jones wrote:
On Mon, Apr 02, 2012 at 08:32:56PM +0200, Miloslav Trmač wrote:
* #834 F18 Feature: /tmp on tmpfs -
http://fedoraproject.org/wiki/F
On 04/06/2012 01:47 PM, Marcela Mašláňová wrote:
On 04/06/2012 11:14 AM, Vratislav Podzimek wrote:
On Mon, 2012-04-02 at 20:58 +0100, Richard W.M. Jones wrote:
On Mon, Apr 02, 2012 at 08:32:56PM +0200, Miloslav Trmač wrote:
* #834 F18 Feature: /tmp on tmpfs -
http://fedoraproject.org/wiki/Feat
On 04/06/2012 11:14 AM, Vratislav Podzimek wrote:
On Mon, 2012-04-02 at 20:58 +0100, Richard W.M. Jones wrote:
On Mon, Apr 02, 2012 at 08:32:56PM +0200, Miloslav Trmač wrote:
* #834 F18 Feature: /tmp on tmpfs -
http://fedoraproject.org/wiki/Features/tmp-on-tmpfs (mitr, 17:40:06)
* AGREED
On Mon, 2012-04-02 at 20:58 +0100, Richard W.M. Jones wrote:
> On Mon, Apr 02, 2012 at 08:32:56PM +0200, Miloslav Trmač wrote:
> > * #834 F18 Feature: /tmp on tmpfs -
> > http://fedoraproject.org/wiki/Features/tmp-on-tmpfs (mitr, 17:40:06)
> > * AGREED: tmp-on-tmpfs is accepted (+5 -3) (mitr,
On 04/04/2012 01:36 PM, Tomasz Torcz wrote:
On Wed, Apr 04, 2012 at 11:51:08AM +0200, Kevin Kofler wrote:
drago01 wrote:
We could just make anaconda remove everything in /tmp ... done.
First of all, renaming it as Simo Sorce suggested makes more sense.
But secondly, what you both miss is tha
On Wed, 04.04.12 09:31, Jonathan Underwood (jonathan.underw...@gmail.com) wrote:
> On 2 April 2012 20:58, Richard W.M. Jones wrote:
> > On Mon, Apr 02, 2012 at 08:32:56PM +0200, Miloslav Trmač wrote:
> >> * #834 F18 Feature: /tmp on tmpfs -
> >> http://fedoraproject.org/wiki/Features/tmp-on-tmp
On Wed, Apr 04, 2012 at 11:51:08AM +0200, Kevin Kofler wrote:
> drago01 wrote:
> > We could just make anaconda remove everything in /tmp ... done.
>
> First of all, renaming it as Simo Sorce suggested makes more sense.
>
> But secondly, what you both miss is that not everyone upgrades using
> An
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/04/2012 04:31 AM, Jonathan Underwood wrote:
> On 2 April 2012 20:58, Richard W.M. Jones wrote:
>> On Mon, Apr 02, 2012 at 08:32:56PM +0200, Miloslav Trmač wrote:
>>> * #834 F18 Feature: /tmp on tmpfs -
>>> http://fedoraproject.org/wiki/Features
drago01 wrote:
> We could just make anaconda remove everything in /tmp ... done.
First of all, renaming it as Simo Sorce suggested makes more sense.
But secondly, what you both miss is that not everyone upgrades using
Anaconda, there's also plain yum. Seeing more and more black magic getting
ad
On Mon, Apr 02, 2012 at 08:58:12PM +0100, Richard W.M. Jones wrote:
> On Mon, Apr 02, 2012 at 08:32:56PM +0200, Miloslav Trmač wrote:
> > * #834 F18 Feature: /tmp on tmpfs -
> > http://fedoraproject.org/wiki/Features/tmp-on-tmpfs (mitr, 17:40:06)
> > * AGREED: tmp-on-tmpfs is accepted (+5 -3)
On 2 April 2012 20:58, Richard W.M. Jones wrote:
> On Mon, Apr 02, 2012 at 08:32:56PM +0200, Miloslav Trmač wrote:
>> * #834 F18 Feature: /tmp on tmpfs -
>> http://fedoraproject.org/wiki/Features/tmp-on-tmpfs (mitr, 17:40:06)
>> * AGREED: tmp-on-tmpfs is accepted (+5 -3) (mitr, 18:12:52)
Do
On Tue, 03.04.12 12:30, Steve Clark (scl...@netwolves.com) wrote:
> >Also, on servers where there are users with shell access, I'll typically
> >limit the size of /tmp with an option in fstab (the default is RAM/2,
> >which can be larger than I'd like). However, reading the feature page,
> >this
Dne 3.4.2012 18:09, Michael Cronenworth napsal(a):
Michal Schmidt wrote:
Cleanup of old files is already done, by systemd-tmpfiles.
See /usr/lib/tmpfiles.d/tmp.conf.
Files, yes. Directories, no.
It removes old directories too.
Due to a bug[1] in gvfs, I had over 100 old, empty directories
On 04/03/2012 04:50 AM, Reindl Harald wrote:
>
>
> Am 03.04.2012 09:17, schrieb drago01:
>> I don't really get why people make so much fuss about a non issue
>> really. 99,99% of the users won't even notice that anything changed at
>> all.
>
> for this 99.9% the current behavior is also good eno
Am 03.04.2012 09:17, schrieb drago01:
> I don't really get why people make so much fuss about a non issue
> really. 99,99% of the users won't even notice that anything changed at
> all.
for this 99.9% the current behavior is also good enough
if they do not notice any change
the other 0.1% are s
On Tue, 2012-04-03 at 10:35 -0500, Chris Adams wrote:
> Once upon a time, Brian Wheeler said:
> > * The competition for space between things in /tmp and VM. When someone
> > abuses space in /tmp (on purpose or not) then the system is going to
> > start swapping and performance is going to suffe
On 04/03/2012 11:35 AM, Chris Adams wrote:
Once upon a time, Brian Wheeler said:
* The competition for space between things in /tmp and VM. When someone
abuses space in /tmp (on purpose or not) then the system is going to
start swapping and performance is going to suffer and the common
respons
Michal Schmidt wrote:
> Cleanup of old files is already done, by systemd-tmpfiles.
> See /usr/lib/tmpfiles.d/tmp.conf.
Files, yes. Directories, no.
Due to a bug[1] in gvfs, I had over 100 old, empty directories in /tmp.
Other apps may fill /tmp with directories, too, that will not be cleaned
by a
Once upon a time, M A Young said:
> On Tue, 3 Apr 2012, Chris Adams wrote:
> >Also, if some user has taken up lots of space in /tmp, you can LART the
> >user and delete the files; that's no different than a user filling up a
> >partition by writing to /tmp (no reboot necessary in either case).
>
On Tue, 03.04.12 08:31, Chris Murphy (li...@colorremedies.com) wrote:
> My only concern about it being on tmpfs instead of on disk, is how big
> it could get, how much memory could be held hostage, until there's a
> reboot. I'd rather see it be both size and age limited (each item has
> a decay ra
On Apr 3, 2012, at 9:48 AM, M A Young wrote:
> On Tue, 3 Apr 2012, Chris Adams wrote:
>
>> Also, if some user has taken up lots of space in /tmp, you can LART the user
>> and delete the files; that's no different than a user filling up a partition
>> by writing to /tmp (no reboot necessary in
On Apr 3, 2012, at 9:35 AM, Chris Adams wrote:
> Once upon a time, Brian Wheeler said:
>> * The competition for space between things in /tmp and VM. When someone
>> abuses space in /tmp (on purpose or not) then the system is going to
>> start swapping and performance is going to suffer and the
On Tue, 3 Apr 2012, Chris Adams wrote:
Also, if some user has taken up lots of space in /tmp, you can LART the
user and delete the files; that's no different than a user filling up a
partition by writing to /tmp (no reboot necessary in either case).
That assumes your system is still functiona
Dne 3.4.2012 16:31, Chris Murphy napsal(a):
My only concern about it being on tmpfs instead of on disk, is how
big it could get, how much memory could be held hostage, until
there's a reboot. I'd rather see it be both size and age limited
(each item has a decay rate or something), so that it's ev
Once upon a time, Brian Wheeler said:
> * The competition for space between things in /tmp and VM. When someone
> abuses space in /tmp (on purpose or not) then the system is going to
> start swapping and performance is going to suffer and the common
> response for fixing it will end up being '
On 04/03/2012 10:31 AM, Chris Murphy wrote:
/tmp is a like a litter box. From a user perspective, I'm happy to have it
emptied regularly, because clearly the cats don't clean up their own doodles.
That one of the cats might think he's deposited something valuable that he'll
come back for somed
/tmp is a like a litter box. From a user perspective, I'm happy to have it
emptied regularly, because clearly the cats don't clean up their own doodles.
That one of the cats might think he's deposited something valuable that he'll
come back for someday, is hilarious to me, as well as ridiculous.
On Tue, Apr 3, 2012 at 8:38 AM, Steve Clark wrote:
> On 04/02/2012 05:30 PM, M A Young wrote:
>
> On Mon, 2 Apr 2012, Lennart Poettering wrote:
>
> On Mon, 02.04.12 16:55, Steve Grubb (sgr...@redhat.com) wrote:
>
> What about forensics? Any reboot erases information that might have been
> needed
>
On 04/02/2012 05:30 PM, M A Young wrote:
On Mon, 2 Apr 2012, Lennart Poettering wrote:
On Mon, 02.04.12 16:55, Steve Grubb (sgr...@redhat.com) wrote:
What about forensics? Any reboot erases information that might have been needed
to see what happened during a break in.
/tmp is already volatil
On Tue, 2012-04-03 at 05:10 +0200, Kevin Kofler wrote:
> Richard W.M. Jones wrote:
> > Actually I think this is a good feature, but ...
>
> I'm unsure about whether this makes sense for new installs or not, but I
> feel my objection in
> https://fedoraproject.org/wiki/Talk:Features/tmp-on-tmpfs w
Daniel J Walsh wrote:
...
> I have been running with a tmpfs /tmp for years, without a problem. I have
> found the having /tmp be anything else that a tmpfs has caused me pain over
> the years with mislabeled files or files with the wrong UID.
>
> Change to use a confined user or change the UID of
On Tue, Apr 3, 2012 at 5:10 AM, Kevin Kofler wrote:
> Richard W.M. Jones wrote:
>> Actually I think this is a good feature, but ...
>
> I'm unsure about whether this makes sense for new installs or not, but I
> feel my objection in
> https://fedoraproject.org/wiki/Talk:Features/tmp-on-tmpfs was no
On Tue, Apr 3, 2012 at 3:28 AM, Brian Wheeler wrote:
> I can't say that as a user (and sysadmin) I'm really thrilled with this.
> /tmp doesn't go away on reboots now so this is a biggish change from my point
> of view.
That's what /tmp has always meant to be i.e a temporary filesystem
that is
Richard W.M. Jones wrote:
> Actually I think this is a good feature, but ...
I'm unsure about whether this makes sense for new installs or not, but I
feel my objection in
https://fedoraproject.org/wiki/Talk:Features/tmp-on-tmpfs was not taken into
account at all. :-/ Forcing this change on upgra
On 04/02/2012 07:44 PM, Dave Jones wrote:
On Mon, Apr 02, 2012 at 06:34:59PM -0400, Przemek Klosowski wrote:
> On Mon, Apr 02, 2012 at 08:32:56PM +0200, Miloslav Trmač wrote:
> >* #834 F18 Feature: /tmp on tmpfs -
> >http://fedoraproject.org/wiki/Features/tmp-on-tmpfs (mitr, 17:40:0
On Mon, Apr 02, 2012 at 06:34:59PM -0400, Przemek Klosowski wrote:
> On Mon, Apr 02, 2012 at 08:32:56PM +0200, Miloslav Trmač wrote:
> >* #834 F18 Feature: /tmp on tmpfs -
> > http://fedoraproject.org/wiki/Features/tmp-on-tmpfs (mitr, 17:40:06)
> > * AGREED: tmp-on-tmpfs is accepted (+5 -3
Am 03.04.2012 00:34, schrieb Przemek Klosowski:
> On Mon, Apr 02, 2012 at 08:32:56PM +0200, Miloslav Trmač wrote:
>> * #834 F18 Feature: /tmp on tmpfs -
>>http://fedoraproject.org/wiki/Features/tmp-on-tmpfs (mitr, 17:40:06)
>>* AGREED: tmp-on-tmpfs is accepted (+5 -3) (mitr, 18:12:52)
>
On Mon, Apr 02, 2012 at 08:32:56PM +0200, Miloslav Trmač wrote:
* #834 F18 Feature: /tmp on tmpfs -
http://fedoraproject.org/wiki/Features/tmp-on-tmpfs (mitr, 17:40:06)
* AGREED: tmp-on-tmpfs is accepted (+5 -3) (mitr, 18:12:52)
The wiki page says:
By implementing this we, by default,
* M A Young [02/04/2012 23:51] :
>
> This also means a big change in user experience as many will be
> expecting things in /tmp to remain there for a while before being
> deleted even if the system is restarted or crashes.
The expectations of these 'many' (this really needs to be measured)
run cou
On Mon, 2 Apr 2012, Lennart Poettering wrote:
On Mon, 02.04.12 16:55, Steve Grubb (sgr...@redhat.com) wrote:
What about forensics? Any reboot erases information that might have been needed
to see what happened during a break in.
/tmp is already volatile and cleaned up in regular intervals. T
On 2 April 2012 14:55, Steve Grubb wrote:
> On Monday, April 02, 2012 03:58:12 PM Richard W.M. Jones wrote:
>> > * #834 F18 Feature: /tmp on tmpfs -
>> >
>> > http://fedoraproject.org/wiki/Features/tmp-on-tmpfs (mitr, 17:40:06)
>> > * AGREED: tmp-on-tmpfs is accepted (+5 -3) (mitr, 18:12:52)
On Mon, Apr 02, 2012 at 20:58:12 +0100,
"Richard W.M. Jones" wrote:
- it doesn't support O_DIRECT
I thought this was also true of ext4 with data journaling enabled.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Richard W.M. Jones (rjo...@redhat.com) said:
> > > - it doesn't support user extended attrs; and not very old kernels
> > > didn't support any xattrs at all, meaning things like SELinux
> > > labels don't work
> >
> > Huh? Why would you run a "very old kernel" on fedora?
>
> It's not unknow
On Mon, 02.04.12 16:55, Steve Grubb (sgr...@redhat.com) wrote:
> On Monday, April 02, 2012 03:58:12 PM Richard W.M. Jones wrote:
> > > * #834 F18 Feature: /tmp on tmpfs -
> > >
> > > http://fedoraproject.org/wiki/Features/tmp-on-tmpfs (mitr, 17:40:06)
> > > * AGREED: tmp-on-tmpfs is accepted
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/02/2012 04:25 PM, Lennart Poettering wrote:
> On Mon, 02.04.12 20:58, Richard W.M. Jones (rjo...@redhat.com) wrote:
> Heya,
>
>> The feature page is wrong about "The user experience should barely
>> change. This is mostly a low-level change t
On Monday, April 02, 2012 03:58:12 PM Richard W.M. Jones wrote:
> > * #834 F18 Feature: /tmp on tmpfs -
> >
> > http://fedoraproject.org/wiki/Features/tmp-on-tmpfs (mitr, 17:40:06)
> > * AGREED: tmp-on-tmpfs is accepted (+5 -3) (mitr, 18:12:52)
>
> Actually I think this is a good feature, bu
On Mon, Apr 02, 2012 at 04:40:38PM -0400, David Quigley wrote:
> You don't specify seclabel as an option. It is something that is put
> into the mount command to show you that a filesystem supports being
> able to set security labels on it.
OK, I see. In fact I tested this and I was able to set S
On Mon, 02.04.12 21:30, Richard W.M. Jones (rjo...@redhat.com) wrote:
> > > - it doesn't support user extended attrs; and not very old kernels
> > > didn't support any xattrs at all, meaning things like SELinux
> > > labels don't work
> >
> > Huh? Why would you run a "very old kernel" on fed
On 04/02/2012 16:26, Richard W.M. Jones wrote:
On Mon, Apr 02, 2012 at 04:11:24PM -0400, David Quigley wrote:
On 04/02/2012 16:06, Richard W.M. Jones wrote:
>That's not what I said. I said that relatively recent kernels (up
to
>the middle of last year) didn't support system.*, and tmpfs doesn
On Mon, Apr 02, 2012 at 10:24:38PM +0200, drago01 wrote:
> On Mon, Apr 2, 2012 at 9:58 PM, Richard W.M. Jones wrote:
> > - it doesn't support O_DIRECT
>
> Neither does this (which apps needs O_DIRECT on /tmp ? ).
qemu and libguestfs as it turned out. It was one of the things we had
to fix when
On Mon, Apr 02, 2012 at 04:11:24PM -0400, David Quigley wrote:
> On 04/02/2012 16:06, Richard W.M. Jones wrote:
> >That's not what I said. I said that relatively recent kernels (up to
> >the middle of last year) didn't support system.*, and tmpfs doesn't
Sorry, I meant to write security.* there.
On Mon, 02.04.12 20:58, Richard W.M. Jones (rjo...@redhat.com) wrote:
Heya,
> The feature page is wrong about "The user experience should barely
> change. This is mostly a low-level change that has little visibility
> to the user."
Well, i'd claim this is not really user visible if implemented
c
On Mon, Apr 2, 2012 at 9:58 PM, Richard W.M. Jones wrote:
> On Mon, Apr 02, 2012 at 08:32:56PM +0200, Miloslav Trmač wrote:
>> * #834 F18 Feature: /tmp on tmpfs -
>> http://fedoraproject.org/wiki/Features/tmp-on-tmpfs (mitr, 17:40:06)
>> * AGREED: tmp-on-tmpfs is accepted (+5 -3) (mitr, 18:1
On 04/02/2012 16:06, Richard W.M. Jones wrote:
On Mon, Apr 02, 2012 at 04:04:23PM -0400, David Quigley wrote:
On 04/02/2012 15:58, Richard W.M. Jones wrote:
>On Mon, Apr 02, 2012 at 08:32:56PM +0200, Miloslav Trmač wrote:
>>* #834 F18 Feature: /tmp on tmpfs -
>> http://fedoraproject.org/wiki/Fe
On Mon, Apr 02, 2012 at 04:04:23PM -0400, David Quigley wrote:
> On 04/02/2012 15:58, Richard W.M. Jones wrote:
> >On Mon, Apr 02, 2012 at 08:32:56PM +0200, Miloslav Trmač wrote:
> >>* #834 F18 Feature: /tmp on tmpfs -
> >> http://fedoraproject.org/wiki/Features/tmp-on-tmpfs (mitr,
> >>17:40:06)
On 04/02/2012 15:58, Richard W.M. Jones wrote:
On Mon, Apr 02, 2012 at 08:32:56PM +0200, Miloslav Trmač wrote:
* #834 F18 Feature: /tmp on tmpfs -
http://fedoraproject.org/wiki/Features/tmp-on-tmpfs (mitr,
17:40:06)
* AGREED: tmp-on-tmpfs is accepted (+5 -3) (mitr, 18:12:52)
Actually I
74 matches
Mail list logo
