Re: [gentoo-user] SSDs, swap, caching, other unusual uses

[Michael Mol]

On Sun, Jul 31, 2011 at 10:02 AM, Volker Armin Hemmann
<volkerarmin@××××××××××.com> wrote:
> On Friday 29 July 2011 14:18:41 Michael Mol wrote:
>> Something that's been tickling my brain for a couple years now, and
>> you guys are probably the right ones to ask.
>>
>> I haven't dropped coin for an SSD (yet), but I was wondering about
>> uses for them beyond using them for / or /home.
>>
>> 1) What about sitting swap (partition, file, whatever) on the SSD?
>
> NO!
>
> For $DEITY's sake- NO!
>
> ssds can't withstand many writes (yeah, I know, millions blablabla... earlier
> done than you think). Do Not Do This.
>
> SSDs are not meant for such a scenario.

I'm not one to care what a tool was meant for, only what it can be used for.

While I take your point about write-cycle limitations, and I would
*assume* you're familiar with the various improvements on
wear-leveling technique that have happened over the past *ten years*
since those concerns were first raised, I could probably raise an
argument that a fresh SSD is likely to last longer as a swap device
than as a filesystem.

Swap is only touched as-needed, while there's been an explosion in
programs and user software which demands synchronous writes to disk
for data integrity purposes. (Firefox uses sqlite in such a way, for
example; I discovered this when I was using sqlite heavily in my *own*
application, and Firefox hung for a couple minutes during every batch
insert.)

Also, despite the MBTF data provided by the manufacturers, there's
more empirical evidence that the drives expire faster than expected,
anyway. I'm aware of this, and not particularly concerned about it.

>
>> Presumably, in scenarios where expanding the RAM in a system is
>> prohibitively expensive, an SSD could reduce the impact of swap
>> thrash.
>
> no, it is increasing the impact of SSD trash.

False dichotomy. Yes, it increases the wear on the device. That says
nothing of its impact on system performance, which was the nature of
my point.

>
>> 2) While my system rarely goes above using 2-2.5GB of RAM, I enjoy
>> having 6-8GB of RAM, just for the file cache. Of course, I lose that
>> when I reboot; the cache needs to be repopulated. Has there been any
>> work in the kernel for doing things like Vista/Win7's ReadyBoost?
>> ReadyBoost has a ridiculous limit to only using 4GB of a flash drive,
>> but I'd think that an 80GB SSD would be a massive performance
>> improvement.
>>
>
> with a SSD filecache is not that important anymore - and every usb-stick is
> slower than a SSD.

I'll poke the second argument first. I wouldn't use USB for something
like this. USB2 is a painfully slow polling architecture. Something
like this would need to be done with SATA. I'm *not* that daft.

As for a filecache not being that important, that's only the case if
your data of interest exists on the filesystem you put on the SSD.

Let's say you're someone like me, who would tend to go with 60GB for /
and 3TB for /home. At various times, I'll be doing HDR photo
processing, some video transcoding, some random non-portage compile
jobs, web browsing, coding, etc.

If I take a 160GB SSD, I could put / (or, at least, /var/ and /usr),
and have some space left over for scratch--but it's going to be a pain
trying to figure out which of my 3TB of /home data I want in that fast
scratch.

File cache is great, because it takes caches your most-used data from
*anywhere* and keeps it in a fast-access datastore. I could have a 3
*petabyte* volume, not be particularly concerned about data
distribution, and have just as response from the filecache as if I had
a mere 30GB volume. Putting a filesystem on an SSD simply cannot scale
that way.

Actually, this conversation reminds me of another idea I'd had at one
point...putting ext3/ext4's journal on an SSD, while keeping the bulk
of the data on large, dense spinning platters.

>
>> Obviously, for something like Gentoo, putting an SSD-based filesystem
>> under /var/tmp makes a lot of sense, but what other uses have been
>> tried? How'd they work out?
>
> no, /var/tmp is very not important from a performance point of view - with the
> exception of /var/tmp/portage - and that is a candidate for tempfs.

Did you miss the last week's worth of discussion of memory limits on tmpfs?

-- 
:wq