On Sun, Jul 31, 2011 at 10:02 AM, Volker Armin Hemmann <volkerar...@googlemail.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
