Wouter Verhelst wou...@debian.org writes:
On Sun, Jun 24, 2012 at 09:54:22PM +0200, Stephan Seitz wrote:
On Sat, Jun 23, 2012 at 11:43:03PM +0200, Wouter Verhelst wrote:
Meanwhile, you've got a non-FHS directory on your system that is of no
immediate use.
Your later suggested /store as a
Henrique de Moraes Holschuh h...@debian.org writes:
On Sun, 24 Jun 2012, Goswin von Brederlow wrote:
Henrique de Moraes Holschuh h...@debian.org writes:
I've read that some SSDs really *dislike* the way Linux does TRIM
batching (or doesn't :p), so yes, it may well be that on most SSDs
Henrique de Moraes Holschuh h...@debian.org writes:
On Sun, 24 Jun 2012, Osamu Aoki wrote:
On Sat, Jun 23, 2012 at 06:00:15PM +0300, Touko Korpela wrote:
Tollef Fog Heen wrote:
On Sun, Jun 10, 2012 at 07:46:57PM +0200, Stephan Seitz wrote:
On Sun, Jun 10, 2012 at 07:12:11PM +0200,
On Sun, 24 Jun 2012, Goswin von Brederlow wrote:
Henrique de Moraes Holschuh h...@debian.org writes:
I've read that some SSDs really *dislike* the way Linux does TRIM
batching (or doesn't :p), so yes, it may well be that on most SSDs
regular fstrim will do much better.
I'm assuming this
On Sat, Jun 23, 2012 at 11:43:03PM +0200, Wouter Verhelst wrote:
On Thu, Jun 21, 2012 at 03:46:16PM +0200, Stephan Seitz wrote:
So most of your Debian systems have several users working at the
same time on the same system? Okay, then you have a different user
base.
webserver.
Sorry, I
On Sun, Jun 24, 2012 at 09:54:22PM +0200, Stephan Seitz wrote:
On Sat, Jun 23, 2012 at 11:43:03PM +0200, Wouter Verhelst wrote:
Meanwhile, you've got a non-FHS directory on your system that is of no
immediate use.
Your later suggested /store as a user /tmp replacement is a non-FHS
directory
Tollef Fog Heen wrote:
On Sun, Jun 10, 2012 at 07:46:57PM +0200, Stephan Seitz wrote:
On Sun, Jun 10, 2012 at 07:12:11PM +0200, Tollef Fog Heen wrote:
]] Stephan Seitz
Will Wheezy support SSDs out of the box with all trimming functions,
even if your SSD partition is using LUKS and
On Sat, Jun 23, 2012 at 06:00:15PM +0300, Touko Korpela wrote:
Tollef Fog Heen wrote:
You need to enable it in all layers (fstab, crypttab, lvm.conf), yes.
For now you shouldn't use discard option with SSDs, it's bad for
performance. Better is to run fstrim periodically.
Does this mean you
On Thu, Jun 21, 2012 at 03:46:16PM +0200, Stephan Seitz wrote:
On Thu, Jun 21, 2012 at 09:06:30AM +0200, Wouter Verhelst wrote:
Maybe, but we are talking about defaults. Please correct me, but I
think that most Debian systems are in some way single user systems.
Not in my experience.
So
On Sat, Jun 23, 2012 at 06:00:15PM +0300, Touko Korpela wrote:
Tollef Fog Heen wrote:
On Sun, Jun 10, 2012 at 07:46:57PM +0200, Stephan Seitz wrote:
On Sun, Jun 10, 2012 at 07:12:11PM +0200, Tollef Fog Heen wrote:
]] Stephan Seitz
Will Wheezy support SSDs out of the box with all
On Sun, 24 Jun 2012, Osamu Aoki wrote:
On Sat, Jun 23, 2012 at 06:00:15PM +0300, Touko Korpela wrote:
Tollef Fog Heen wrote:
On Sun, Jun 10, 2012 at 07:46:57PM +0200, Stephan Seitz wrote:
On Sun, Jun 10, 2012 at 07:12:11PM +0200, Tollef Fog Heen wrote:
]] Stephan Seitz
Will
2012/6/19 Wouter Verhelst wrote:
That's not true. Only applications, that are limited by /tmp speed will
become faster then. Do you know such applications?
Any application which performs I/O anywhere has a chance of being
limited by it.
In theory. But do you know any applications actually
On Mi, 20 iun 12, 15:18:55, Stephan Seitz wrote:
Fine let’s talk. Why can’t we find a compromise? Additional to our
disk /tmp we create a /ramtmp (so the name suggests that this tmp is
a ramdisk) with tmpfs. This should be doable in time for Wheezy. The
release notes should mention it. And
On Fri, 22 Jun 2012, Andrei POPESCU wrote:
On Mi, 20 iun 12, 15:18:55, Stephan Seitz wrote:
Fine let’s talk. Why can’t we find a compromise? Additional to our
disk /tmp we create a /ramtmp (so the name suggests that this tmp is
a ramdisk) with tmpfs. This should be doable in time for
On Wed, Jun 20, 2012 at 03:18:55PM +0200, Stephan Seitz wrote:
On Mon, Jun 18, 2012 at 11:42:06PM +0200, Wouter Verhelst wrote:
If you write to /tmp on disk and someone or something calls sync at
precisely the wrong moment, you're stuck, and your performance suffers.
Not so with tmpfs.
On Thu, Jun 21, 2012 at 09:06:30AM +0200, Wouter Verhelst wrote:
Maybe, but we are talking about defaults. Please correct me, but I
think that most Debian systems are in some way single user systems.
Not in my experience.
So most of your Debian systems have several users working at the same
Dnia 2012-06-21, czw o godzinie 09:06 +0200, Wouter Verhelst pisze:
[ cut ]
Yes; but if you're going to make /tmp be a separate partition, then your
argument that there's more space on disk doesn't really hold anymore,
either, since now /tmp is much much smaller than your disk (I've never
seen
Stephan Seitz stse+deb...@fsing.rootsland.net writes:
On Thu, Jun 21, 2012 at 09:06:30AM +0200, Wouter Verhelst wrote:
Maybe, but we are talking about defaults. Please correct me, but I
think that most Debian systems are in some way single user systems.
Not in my experience.
So most of
On Wed, Jun 20, 2012 at 09:08:51PM +0200, Carlos Alberto Lopez Perez wrote:
On 20/06/12 15:18, Stephan Seitz wrote:
Fine let’s talk. Why can’t we find a compromise? Additional to our disk
/tmp we create a /ramtmp (so the name suggests that this tmp is a
ramdisk) with tmpfs. This should
On Thu, Jun 21, 2012 at 10:20:03PM +0200, David Weinehall wrote:
because I think it'd be impossible to convince some people that /tmp
isn't a random dumping ground for anything and everything.
But what is /tmp for you? Since my first Unix experience in the 90s, /tmp
was always the local disk
On Mon, Jun 18, 2012 at 11:42:06PM +0200, Wouter Verhelst wrote:
If you write to /tmp on disk and someone or something calls sync at
precisely the wrong moment, you're stuck, and your performance suffers.
Not so with tmpfs.
Maybe, but we are talking about defaults. Please correct me, but I
On 20/06/12 15:18, Stephan Seitz wrote:
Fine let’s talk. Why can’t we find a compromise? Additional to our disk
/tmp we create a /ramtmp (so the name suggests that this tmp is a
ramdisk) with tmpfs. This should be doable in time for Wheezy. The
release notes should mention it. And those who
Wouter Verhelst wou...@debian.org writes:
On Wed, Jun 13, 2012 at 04:14:52AM +0300, Serge wrote:
User cannot break the system filling /tmp on disk. But he can do that
if he fills /tmp on tmpfs. So /tmp on tmpfs adds one more point of
failure for servers.
No, that's not true. The real danger
On Wed, Jun 13, 2012 at 04:14:52AM +0300, Serge wrote:
2012/6/10 Wouter Verhelst wrote:
A lot of people (including you) said that tmpfs makes things faster. But
there were no examples of popular use-cases becoming faster because
of /tmp on tmpfs, so I had nothing to quote.
You're not
Wouter Verhelst wrote:
I don't think compiling C code has been CPU bound since before I was
born (and I was born in the late 70s, so that's quite a while). C++ is a
different matter, but still.
Bullshit. GCC uses a lot of CPU unless you compile without optimization,
and is surprisingly slow
Le mercredi 13 juin 2012 à 04:14 +0300, Serge a écrit :
Yes. Everything. Every popular /tmp usage that most users expect to work
is limited either by CPU (gcc compiling) or by network speed (browser or
flash temporaries), or is just too fast already (bash heredoc). So moving
/tmp to tmpfs
On Wed, 2012-06-13 at 09:22 +0200, Josselin Mouette wrote:
Le mercredi 13 juin 2012 à 04:14 +0300, Serge a écrit :
Yes. Everything. Every popular /tmp usage that most users expect to work
is limited either by CPU (gcc compiling) or by network speed (browser or
flash temporaries), or is
2012/6/10 Wouter Verhelst wrote:
A lot of people (including you) said that tmpfs makes things faster. But
there were no examples of popular use-cases becoming faster because
of /tmp on tmpfs, so I had nothing to quote.
You're not even trying.
if tmpfs is faster than (say) ext4, then
Le dimanche 10 juin 2012 à 01:51 +0300, Serge a écrit :
Some people asked for a thread summary. So here it is.
/tmp on tmpfs is good quotes
==
No real quotes here.
So much for a thread summary.
--
.''`. Josselin Mouette
: :' :
`. `'
`-
--
To
On Sun, Jun 10, 2012 at 01:51:19AM +0300, Serge wrote:
Some people asked for a thread summary. So here it is.
[Lots of drivel, including thoroughly debunked statements, snipped.
Seriously, can't you even read what's written to you? Sorry for being
angry, but there's a limit to how many times you
On Sun, Jun 10, 2012 at 01:51:19AM +0300, Serge wrote:
Some people asked for a thread summary. So here it is.
Sorry, but this is a biased summary, and therefore useless for what it
intends to be.
[...]
/tmp on tmpfs is good quotes
==
No real quotes here. Most of
2012/6/10 Adam Borowski wrote:
Some people asked for a thread summary. So here it is.
Seriously, can't you even read what's written to you?
Yes, I know it was a biased summary. So as yours. But there's a difference
between mine and yours. Mine is based on some real-world applications,
yours is
Serge sergem...@gmail.com writes:
2012/6/10 Adam Borowski wrote:
Some people asked for a thread summary. So here it is.
Seriously, can't you even read what's written to you?
Yes, I know it was a biased summary.
I think you might start to piss off a few people now...
Look at what you are
2012/6/10 Wouter Verhelst wrote:
Sorry, but this is a biased summary, and therefore useless for what it
intends to be.
Yes, I know. It's biased toward the /tmp and real-world applications.
/tmp on tmpfs is good quotes
No real quotes here. Most of this and other threads were about why
/tmp
Serge wrote:
2012/6/10 Adam Borowski wrote:
Some people asked for a thread summary. So here it is.
Seriously, can't you even read what's written to you?
Yes, I know it was a biased summary. So as yours. But there's a difference
between mine and yours. Mine is based on some real-world
On Sun, Jun 10, 2012 at 12:35:47PM +0200, Adam Borowski wrote:
* Less wear of SSD drives.
• Contrary to Serge's claims, SSDs are not an oddity, and it's not
unlikely these will be a majority before wheezy becomes oldstable.
He didn’t say they were oddities. He said you should more worry
2012/6/10 Uoti Urpala wrote:
Yes, I know it was a biased summary. So as yours. But there's a difference
between mine and yours. Mine is based on some real-world applications,
You've posted blatantly false claims. If you post claims like 1+1
equals 2 because the moon is made of cheese, then
]] Stephan Seitz
Will Wheezy support SSDs out of the box with all trimming functions,
even if your SSD partition is using LUKS and LVM?
Depends on what you mean by out of the box. I suspect you still need to
turn on discard support (since it has security implications). It does
not require
On Sun, Jun 10, 2012 at 07:12:11PM +0200, Tollef Fog Heen wrote:
]] Stephan Seitz
Will Wheezy support SSDs out of the box with all trimming functions,
even if your SSD partition is using LUKS and LVM?
Depends on what you mean by out of the box. I suspect you still need to
turn on discard
On Sun, Jun 10, 2012 at 06:13:24PM +0300, Serge wrote:
2012/6/10 Wouter Verhelst wrote:
Sorry, but this is a biased summary, and therefore useless for what it
intends to be.
Yes, I know. It's biased toward the /tmp and real-world applications.
/tmp on tmpfs is good quotes
No real
On 06/10/2012 11:55 PM, Stephan Seitz wrote:
Well, if I start Virtual Box on my notebook (4 GB RAM), the system
uses the swap partition.
Frankly, I don't know what the fuck virtualbox is doing
with its memory management, but I was tempted more than
once to file a RC bug with a title like this
On Sun, Jun 10, 2012 at 12:35:47PM +0200, Adam Borowski wrote:
On Sun, Jun 10, 2012 at 01:51:19AM +0300, Serge wrote:
Some people asked for a thread summary. So here it is.
But, for the rest of us, here's a different summary.
I've long thought that the wiki might be a good tool for trying to
On Sun, Jun 10, 2012 at 07:46:57PM +0200, Stephan Seitz wrote:
On Sun, Jun 10, 2012 at 07:12:11PM +0200, Tollef Fog Heen wrote:
]] Stephan Seitz
Will Wheezy support SSDs out of the box with all trimming functions,
even if your SSD partition is using LUKS and LVM?
Depends on what you mean by
Serge wrote:
2012/6/10 Uoti Urpala wrote:
You've posted blatantly false claims. If you post claims like 1+1
equals 2 because the moon is made of cheese, then you're a moron, even
if 1+1 does equal 2.
(I like this example :)) It could be, it's impossible to know everything
in the world,
]] Philipp Kern
On Sun, Jun 10, 2012 at 07:46:57PM +0200, Stephan Seitz wrote:
On Sun, Jun 10, 2012 at 07:12:11PM +0200, Tollef Fog Heen wrote:
]] Stephan Seitz
Will Wheezy support SSDs out of the box with all trimming functions,
even if your SSD partition is using LUKS and LVM?
On Sun, Jun 10, 2012 at 10:31:21PM +0200, Tollef Fog Heen wrote:
Well, nice to hear, but I thought, discard was needed in all layers,
so in my example in LUKS, then in LVM and then in the filesystem. Or
is his only a function you activate via hdparm?
It's available in all layers, but as
2012/6/10 Thomas Goirand wrote:
Let's put it this way: I can't run Virtualbox AND
Firefox at the same time, or my laptop becomes unusably
slow and non responsive.
Do you use 2.6 kernel and have FF profile and VB images on the same ext4
partition?
Can you reproduce that with 3.2 kernel?
PS:
Some people asked for a thread summary. So here it is.
Seriously, can't you even read what's written to you?
Yes, I know it was a biased summary.
I think you might start to piss off a few people now...
Look at what you are quoting above. You introduced your biased summary
like this:
2012/6/10 Uoti Urpala wrote:
What false claim are you talking about?
The problem is that you've posted quite a few of those false claims
[...]
For example, the page you linked for your SSDs can take 50 years
of writing before they wear out claim has a first paragraph saying
durability IS
Some people asked for a thread summary. So here it is.
Contents
* Short Problem Summary
* My point
* Initial suggestion - RAMTMP=no + d-i extension
* Later suggestion - RAMTMP=auto
* Other ideas
* Alternatives
- SSD setup - Normal
- SSD setup - Paranoid
* /tmp on tmpfs is good quotes
50 matches
Mail list logo
