Henrique de Moraes Holschuh writes:
> On Sun, 24 Jun 2012, Goswin von Brederlow wrote:
>> Henrique de Moraes Holschuh 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
Wouter Verhelst 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 user /
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
> di
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 ignor
On Sun, 24 Jun 2012, Goswin von Brederlow wrote:
> Henrique de Moraes Holschuh 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 is due
Henrique de Moraes Holschuh 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, T
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 actu
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
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 t
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.
>
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 sh
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
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 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. A
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 f
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.
Stephan Seitz 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 your Debian systems have
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
> s
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
t
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 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 tho
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 th
Wouter Verhelst 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 in filli
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
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.
> >
>
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
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
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, th
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 UNS
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
> durabili
> >>> 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 summa
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:
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 Tol
]] 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
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
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
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
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 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" quote
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 suppo
]] 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
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"
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 abo
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-wo
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
Serge 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 quoting above
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
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
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
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" quote
50 matches
Mail list logo
