FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 06-21-2012, 08:59 PM
Stephan Seitz
 
Default Summary: Moving /tmp to tmpfs makes it useless

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 for temporary things. Yes, it is limited by the
disk size. At university your $HOME was a NFS share (and I don’t know
what you have against NFS for a shared filesystem; do yo prefer CIFS?),
/tmp was always local like swap.


If /tmp isn’t a „dumping ground für anything and everything” as long as
there is enough space, what directory is more fitting?
/tmp is cleaned at every reboot (configurable by TMPTIME), so a user
doesn’t have to worry about it. Do you want something similiar for your
/home/<user>/tmp?


Should we now have different definitions of „temporary file”?

Stephan

--
| Stephan Seitz E-Mail: stse@fsing.rootsland.net |
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |
 
Old 06-22-2012, 05:10 PM
Andrei POPESCU
 
Default Summary: Moving /tmp to tmpfs makes it useless

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 those who wish can patch their
> programs to use the ramdisk if they think their program uses only
> small temporary files. In this way, we get some data and experience.
> And we have both worlds. /tmp on disk for even large temporary files
> and /ramtmp as fast ramdisk.

Why not use /run instead?

Kind regards,
Andrei
--
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
 
Old 06-22-2012, 07:28 PM
Henrique de Moraes Holschuh
 
Default Summary: Moving /tmp to tmpfs makes it useless

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 Wheezy. The
> > release notes should mention it. And those who wish can patch their
> > programs to use the ramdisk if they think their program uses only
> > small temporary files. In this way, we get some data and experience.
> > And we have both worlds. /tmp on disk for even large temporary files
> > and /ramtmp as fast ramdisk.
>
> Why not use /run instead?

Feel free to add a *mountpoint* at /run/tmp and provide a second tmpfs
there[1]. But if you do that, we'd have /tmp, /run/tmp, and /var/tmp so to
me it just looks like a mess...

Well, /var/tmp is always disk-backed and it is supposed to last across
reboots, and files there should last for a while before any automated
cleaning. It is written nowhere that you can leave large files in there,
though, but it is not supposed to be too space-constrained.

/run/tmp might be defined from the get go to be tmpfs, and not some place
you should expect to be able to abuse (i.e. can't be automatically used to
unpack large amounts of crap, host the tile cache of a pixel editor or the
browser's cache, etc). What good would it do, I don't know: you'd need to
set TMPDIR=/run/tmp to use it anyway, so might as well just do it to /tmp...

[1] Should you fill /run or cause a filename colision, very bad things
can happen. You don't use /var/lock and /var/run as a general dumping
ground for random crap, and the same rule applies to /run.

--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120622192819.GC32380@khazad-dum.debian.net">http://lists.debian.org/20120622192819.GC32380@khazad-dum.debian.net
 
Old 06-23-2012, 03:00 PM
Touko Korpela
 
Default Summary: Moving /tmp to tmpfs makes it useless

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 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 extra packages or patches.
> > > 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 Tollef said it's manual. (In crypttab
> > most
> > likely, because that's commonly the lowest layer.)
>
> 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.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/20120623150015.GA24345@lisko
 
Old 06-23-2012, 05:41 PM
Osamu Aoki
 
Default Summary: Moving /tmp to tmpfs makes it useless

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 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 extra packages or patches.
> > > > 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 Tollef said it's manual. (In crypttab
> > > most
> > > likely, because that's commonly the lowest layer.)
> >
> > You need to enable it in all layers (fstab, crypttab, lvm.conf), yes.

This was what I read elsewhere too.

> For now you shouldn't use discard option with SSDs, it's bad for
> performance. Better is to run fstrim periodically.

Could you care to give us pointer to the rational behind your assertion?

Regards,

Osamu


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/20120623174124.GA8582@goofy.localdomain
 
Old 06-23-2012, 09:43 PM
Wouter Verhelst
 
Default Summary: Moving /tmp to tmpfs makes it useless

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 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".

Additionally, in $DAYJOB I do indeed maintain a number of systems where
users log in remotely (through VNC and/or NX) and work on the system,
with several people logged in at the same time.

[...]
> >>I agree, but only if your tmpfs is big enough to hold the file.
> >>Ripping DVDs or BDs will exceed any tmpfs limit on most systems.
> >Not necessarily. Ffmpeg's two-pass video encoding uses a temporary file
> >to which it writes statistics about the video file being processed
>
> Ah, thank you for the explanation, but
>
> >to optimize the encoder in the second pass. This statistics file
> >contains data such as "at time index X, Y% of the image changes" in
> >ASCII form, and hence need not be much larger than some tens of
> >megabytes for a full-sized DVD.
>
> if the file is only about some tens of megabytes, do you really gain
> so much speed?

Yes.

Filesystems and disks are very good at optimizing sequential reads from
a single (large) file if no other disk access happens at the same time.
However, if you write to another file during that sequential access, you
take a performance hit, since now there's more than just one file.

It's not about the size of the file as opposed to about having
additional disk access interfering with optimizations.

Having said that, this is besides the point, really. The point is that
yes, tmpfs is really faster. I gave you a few examples where this is
true, but the examples aren't really the point; the fact that tmpfs is
indeed faster, is. You can maybe convince me that in one or two specific
use cases it won't matter much, but not that it won't matter as a whole.

RAM is faster than disk. That's a fact. Therefore, tmpfs will be faster
than disk, too, and that's an advantage.

Can we stop talking about specific use cases now?

> >>Nobody disagrees that RAM is faster than disk, but I hope you don’t
> >>disagree as well that most people will have more disk space than
> >>RAM.
> >That leads us to the crux of the discussion: we are both right. You are
> >right in that /tmp on disk lowers the chance of /tmp running out of
> >space, which is a real problem. I, and others arguing in favour of
> >tmpfs, are right that placing /tmp on tmpfs will speed up things and (if
> >not using any swap space) will reduce usage of an SSD, both of which
> >are real improvements.
>
> I still think that the SSD problem is not a valid concern as long as
> we don’t have solutions for /var and log daemons. There is more
> traffic in /var than in /tmp.

You're letting the perfect be the enemy of the good, then.

Yes, /var produces changes to storage, too, but that doesn't mean we
shouldn't optimize /tmp because we can't optimize /var. That makes no
sense.

> If we really want to optimize for SSDs we should do something like:
> - /tmp and /var/tmp on tmpfs
> - no local logging or the possibility to enter a log server
> - patching any applications like iceweasel to store their cache on
> a tmpfs
> - running trim daemon for discard (maybe)

I'm not saying we should "optimize for SSDs". I'm just saying that
storing on tmpfs is beneficial for SSDs.

I'm not trying to steer the discussion towards SSDs or anything; I just
think that tmpfs is a good option for /tmp, for various reasons. That we
can get the same effects with other measures is great, but of no
relevance for a discussion about tmpfs.

[...]
> >The question is: what matters most? To me, the performance improvements
> >of tmpfs are significant enough to warrant making it the default.
> >Clearly, you disagree.
>
> Yes, because the performance improvements will only get you speed
> but risk breakage of the application because /tmp is now smaller
> than it was before tmpfs times. On the other hand disk /tmp will
> make some things slower, but in the end it is safer. And I think
> users understand the problem of a full disk much easier than how to
> expand a full ram disk.
>
> >>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 wish can patch their
> >>programs to use the ramdisk if they think their program uses only
> >>small temporary files. In this way, we get some data and experience.
> >>And we have both worlds. /tmp on disk for even large temporary files
> >>and /ramtmp as fast ramdisk.
> >While I think a compromise would be wonderful, I don't think this is it.
> >Additionally, I don't think this is technically and aesthetically a very
> >good solution.
>
> Well, why?

Because it would end up being a directory that nearly nobody would use
directly. Those who want to use a ramdisk will just remove that
directory (or make it a symlink) and mount /tmp on tmpfs instead, and
those who don't want to use it will probably just ignore it.

Also, if deciding on a reasonable default for /tmp is difficult, think
about deciding on a reasonable default for individual packages. That's
going to be even harder.

Meanwhile, you've got a non-FHS directory on your system that is of no
immediate use.

> Other suggestions were to write daemons monitoring tmpfs
> and increasing it if necessary together with swap space. Or writing
> a daemon to blend tmpfs and disk together.
> Besides that these daemons must be written and tested first it
> sounds much to complicated to me.

Wasn't my suggestion, and I agree with you (also, those "solutions"
wouldn't be much cleaner, either)

[...]
> >>But this will only happen if your /tmp is not a separate partition.
> >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 a system with a separate partition for /tmp use more than a few
> >gigs for that partition).
>
> While you are right that /tmp on a separate partition is smaller
> than the disk, you are wrong (at least in my cases) that tmpfs would
> now be bigger than disk /tmp. My smallest disk is 250GB, my biggest
> 2TB, still all my systems have only 4GB RAM. At my company there are
> some systems with 8GB RAM, some even with 16GB (eclipse user), but
> the disks are at least 500GB.
>
> /tmp has always been about 10-20GB big, because I expect users to
> store big temporary images in /tmp. I won’t get this with tmpfs and
> I would have to train the users to change their behaviour.

I believe this is part of our disagreement: I don't think system-wide
directories are meant for users to use directly. In other words, I don't
think users should put large downloads in /tmp; instead, they should put
such files in a subdirectory of their homedirectory -- and if you really
need some scratch space, using some other directory (the systems I
referred to above have fairly large partitions mounted under "/store")
would seem to be preferential.

> >>And it can happen with /var as well. I’ve seen programs logging so
> >>fast that /var had no space left breaking the logging and the
> >>database.
> >Absolutely, I'm not contesting that (in fact, I've recently had a very
> >similar situation at a customer). But this discussion is not about /var,
> >it's about /tmp.
>
> Yes, it is, but if tmpfs is seen as an advantage because /tmp can’t
> block the system anymore and prevent DOS attacks (among others),
> this doesn’t sound so good anymore if you can as easily block the
> system by filling /var/tmp or /var/log.

I don't agree with that argument.

True, the simple fact that the impact of filling up /tmp is reduced
doesn't mean there's no other way anymore to fill up the hard disk. But
that doesn't mean there's suddenly no benefit anymore in avoiding that
pitfall.

And the fact that you can fill up /var and break the system should not
be an argument to allow people to also fill up /tmp and break the
system, "because you can't solve that problem anyway". Sure, you can't,
but that doesn't mean it's not worth it.

If this were a security measure, you might have a point; there's no
reason in filling one security hole but leaving another one wide open.
But this is not about security, it's about common system usage.

--
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120623214303.GZ7471@grep.be">http://lists.debian.org/20120623214303.GZ7471@grep.be
 
Old 06-24-2012, 12:51 AM
Henrique de Moraes Holschuh
 
Default Summary: Moving /tmp to tmpfs makes it useless

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 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 extra packages or patches.
> > > > > 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 Tollef said it's manual. (In crypttab
> > > > most
> > > > likely, because that's commonly the lowest layer.)
> > >
> > > You need to enable it in all layers (fstab, crypttab, lvm.conf), yes.
>
> This was what I read elsewhere too.
>
> > For now you shouldn't use discard option with SSDs, it's bad for
> > performance. Better is to run fstrim periodically.
>
> Could you care to give us pointer to the rational behind your assertion?

Better yet: just tell people to get their own answer, using bonie++.
This is likely to be filesystem-specific, kernel version specific,
storage-stack specific AND device-specific after all.

I've read that some SSDs really *dislike* the way Linux does TRIM
batching (or doesn't ), so yes, it may well be that on most SSDs
regular fstrim will do much better.

--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120624005126.GD20885@khazad-dum.debian.net">http://lists.debian.org/20120624005126.GD20885@khazad-dum.debian.net
 
Old 06-24-2012, 03:08 AM
Serge
 
Default Summary: Moving /tmp to tmpfs makes it useless

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 using that chance?

> 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.

I don't know any examples. Can you suggest one? I mean, what should be
those two programs, one of which calls "sync" while another writing large
data to /tmp so I could measure the performance difference?

> I'm not saying the speedup will be extreme, but it will be there, and
> (cumulated over loads of programs using /tmp) it will be significant
> enough to be noticeable.

If it is noticeable it's great! What'd I do to notice it on my system?

>>> Can I provide a use case where this will matter? Not necessarily. But
>>> then, can you provide a use case where this will *not* matter? Really?
>>
>> Yes. Everything.
>
> Oh, interesting. You have the data to back that claim up?

Every test I posted to this list.

> You make it sound as if those three are the only uses of /tmp. That's
> just not true.

I just named the most popular ones for regular users.

> - The nbd test suite stores fairly large files in $TMPDIR on which it
> then runs nbd-server

How much faster it becomes with tmpfs? Can you do e.g. 5 tests in a row
with tmpfs and then 5 tests without it to compare the difference? If it
can really benefit from tmpfs, then, it's good, it would be the first
real-world program to use tmpfs so far... Also, how large tmpfs does it
need? Is it still faster with tmpfs if tmpfs gets swapped?
(set cpufreq governor to "performance" when doing the test, and stop
`*cron` if tests are too long)

> - Any data transformation or filtering which needs to be done in
> multiple passes over a file would use a temporary file for
> intermediate results

That's a theory. Neither you nor I can answer the question of how much
faster such "any data transformation" will become.

> Multi-pass video transcoding is an example of this, and which
> (depending on the codecs used and the hardware on which it runs) could
> certainly be I/O bound.

It's CPU-bound unless you know some *really* fast codec that I'm not
aware of. Or do you have some example that I can run and see it
becoming faster with tmpfs myself?

> - using mc on a tar.gz which was compressed with --fast

It could be. Is it just a guess, or have you checked it on some real-world
archives? I.e. my test with linux-kernel archive have not confirmed that.

> The point is that neither you nor I can reasonably be expected to list
> all possible uses of /tmp

It's not the point. The point is to find those uses that are limited by /tmp
I/O speed.

> and that RAM is faster than disk, so that when you access a tmpfs you're
> going to be somewhat faster than when you access a disk-backed filesystem

No. That's a theory, and it's wrong. RAM is faster than disk, so
accessing a tmpfs MAY be faster IF you're limited by the I/O speed.
Theories can be wrong, that's why I always ask for examples, tests...

>> Hm, it's a bad idea to use tmpfs with swap... And it's not a good idea
>> to use tmpfs without swap, since it would be too small and may even
>> trigger OOM killer. When is it good to use tmpfs then?
>
> I never used tmpfs on a system with swap, and I've not often seen the
> OOM killer start doing its job. My current machine has 4GiB of RAM,
> which seems to be more than enough.

Heh. You're saying that "tmpfs is not too bad" for you. But it does not
automatically make it good for you.

>> 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 filling up /tmp is not that
> other processes can't write temporary files anymore (causing a minority
> of processes to hang or die; those who just happen to need temporary
> storage at that point in time), but that no process can write any file
> anymore (causing a significant majority of processes to hang or die).

Hrm... But there're no other directories on a root partition that user
can write to. If you mean that /tmp on tmpfs prevents /var or /home from
being filled then it's not true either. Putting /tmp on tmpfs will force
people to use /var/tmp or /home for large files and will (not "can", but
"will", since /var/tmp is not cleaned) eventually fill those partition,
which is exactly what you were trying to prevent.

> Now whether that advantage outweighs the disadvantages you've outlined
> is something we can talk about. However, whether RAM is faster than disk
> isn't;

Why are you limiting it to either "yes" or "no"? There're other options.
It's not about "RAM is faster than disk". It's about "whether there're any
programs becoming noticeably faster because RAM is faster than disk".
Applications are not limited to use /tmp only. And /tmp is not limited to
be either on tmpfs or root partitions. There're other options.

For example, if we find just one package, becoming faster because of tmpfs,
great, then we'll patch that package to include /var/ram directory and
configure it to mount tmpfs there and use it by default.

If we find 5 of such programs, great!, we can have a separate package
`varram.deb`, that sets up tmpfs for /var/ram, and set it as dependency
to those programs. We can even limit /var/ram write ACLs to e.g. `varram`
group, so that regular users could not DoS those programs by filling it.

The only case when we need /tmp on tmpfs is when there're more programs
benefiting from it than programs broken by it. In that case it would be
easier to patch programs, broken by tmpfs, than patch all the programs
becoming faster. But the problem is: we had not found ANY programs
becoming faster because of tmpfs and not being broken by it.
At least I have not seen a reproducible benchmark yet. Have you?

PS: Sometimes I don't understand people. I'm trying to find a solution
that is good/fast for every use-case possible, but people don't want to
name those use-cases... Why?

Isn't it easier to give some reproducible real-world example instead of
writing all those theories and philosophical debates?

--
Talk is cheap. Show me the code. (c) Linus
Serge


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/CAOVenEpz5KzseYYhxEj1okt6ipms21pS764Cx6q1OM0=Z39LD g@mail.gmail.com
 
Old 06-24-2012, 10:42 AM
Goswin von Brederlow
 
Default Summary: Moving /tmp to tmpfs makes it useless

Henrique de Moraes Holschuh <hmh@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, 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 support (since it has security implications). It does
>> > > > > >not require extra packages or patches.
>> > > > > 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 Tollef said it's manual. (In crypttab
>> > > > most
>> > > > likely, because that's commonly the lowest layer.)
>> > >
>> > > You need to enable it in all layers (fstab, crypttab, lvm.conf), yes.
>>
>> This was what I read elsewhere too.
>>
>> > For now you shouldn't use discard option with SSDs, it's bad for
>> > performance. Better is to run fstrim periodically.
>>
>> Could you care to give us pointer to the rational behind your assertion?
>
> Better yet: just tell people to get their own answer, using bonie++.
> This is likely to be filesystem-specific, kernel version specific,
> storage-stack specific AND device-specific after all.
>
> I've read that some SSDs really *dislike* the way Linux does TRIM
> batching (or doesn't ), so yes, it may well be that on most SSDs
> regular fstrim will do much better.

I'm assuming this is due to fragmentation. With TRIM you get lots of
small free chunks. With fstrim you get huge batches.

But if the disk doesn't defrag then won't it just be a matter of time
for it to get slow with fstrim too?

MfG
Goswin


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/87fw9l7zyr.fsf@frosties.localnet
 
Old 06-24-2012, 02:13 PM
Henrique de Moraes Holschuh
 
Default Summary: Moving /tmp to tmpfs makes it useless

On Sun, 24 Jun 2012, Goswin von Brederlow wrote:
> Henrique de Moraes Holschuh <hmh@debian.org> writes:
> > I've read that some SSDs really *dislike* the way Linux does TRIM
> > batching (or doesn't ), so yes, it may well be that on most SSDs
> > regular fstrim will do much better.
>
> I'm assuming this is due to fragmentation. With TRIM you get lots of
> small free chunks. With fstrim you get huge batches.

AFAIK, it is related to trim requests not being of the same type as
write/read requests (so you have to drain the queue of all in-flight
commands or something), some SSDs being allergic to large batched trim
requests while others are allergic to unbatched small trim requests,
bershitty implementation of said command in SSDs (high latency,
synchronous), etc. On top of whatever performance issues the Linux support
for TRIM at the storage stack and filesystems might have.

It may well have no fix. fstrim is not performance sensitive (people will
run it when they have the time to wait for it to complete), so it doesn't
matter if the SSD is very bad at TRIM and goes out for lunch for several
seconds per trim request...

> But if the disk doesn't defrag then won't it just be a matter of time
> for it to get slow with fstrim too?

Any SSD worth its price has both the reserved flash and the background
garbage collection systems required to defrag itself if left idle for long
enough. But regular TRIMming lets it do a much better job.

--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120624141340.GA24236@khazad-dum.debian.net">http://lists.debian.org/20120624141340.GA24236@khazad-dum.debian.net
 

Thread Tools




All times are GMT. The time now is 11:48 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org