Re: 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 :p), 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