Am Sonntag 31 Juli 2011, 10:44:28 schrieb Michael Mol:
> 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*
yeah, I am. Or let it phrase it differently:
I know what is claimed.
The problem is, the best wear leveling does not help you if your disk is
pretty filled up and you still do a lot of writing. 1 000 000 write cycles
aren't much.
> 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.
depends - because thanks to wear leveling that 'swap partition' is just
something the firmware makes the kernel believe to be there.
>
> 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.)
which is another goof reason not to use firefox - but
total used free shared buffers cached
Mem: 8182556 7373736 808820 0 56252 2197064
-/+ buffers/cache: 5120420 3062136
Swap: 23446848 82868 23363980
even with lots of ram, you will hit swap. And since you are using the wear-
leveling of the drive's firmware it does not matter that your swap resides on
its own partition - every page written means a block-rewrite somewhere. Really
not good for your ssd.
>
> 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.
well, it is your money to burn.
>
> >> 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.
if you are so concerned of swap performance you should probably go with a
smaller ssd, get more ram and let that few mb of swap you need been handled by
several swap partitions.
>
> >> 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.
60gb for /, 75gb for /var, and 2.5tb data...
my current setup.
>
> 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.
true, but all those microseconds saved with swap on ssd won't offset the pain
when the ssd dies earlier.
>
> 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.
which sounds nice in theory.
>
> >> 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?
probably. Because I am using tempfs for /var/tmp/portage for ages and the only
problematic packet is openoffice/libreoffice.
--
#163933
