Gentoo Archives: gentoo-user

From: Volker Armin Hemmann <volkerarmin@××××××××××.com>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] SSDs, swap, caching, other unusual uses
Date: Sun, 31 Jul 2011 22:38:43
Message-Id: 2368354.11qjTEMM1R@localhost
In Reply to: Re: [gentoo-user] SSDs, swap, caching, other unusual uses by Michael Mol
1 Am Sonntag 31 Juli 2011, 10:44:28 schrieb Michael Mol:
2 > On Sun, Jul 31, 2011 at 10:02 AM, Volker Armin Hemmann
3 >
4 > <volkerarmin@××××××××××.com> wrote:
5 > > On Friday 29 July 2011 14:18:41 Michael Mol wrote:
6 > >> Something that's been tickling my brain for a couple years now, and
7 > >> you guys are probably the right ones to ask.
8 > >>
9 > >> I haven't dropped coin for an SSD (yet), but I was wondering about
10 > >> uses for them beyond using them for / or /home.
11 > >>
12 > >> 1) What about sitting swap (partition, file, whatever) on the SSD?
13 > >
14 > > NO!
15 > >
16 > > For $DEITY's sake- NO!
17 > >
18 > > ssds can't withstand many writes (yeah, I know, millions blablabla...
19 > > earlier done than you think). Do Not Do This.
20 > >
21 > > SSDs are not meant for such a scenario.
22 >
23 > I'm not one to care what a tool was meant for, only what it can be used for.
24 >
25 > While I take your point about write-cycle limitations, and I would
26 > *assume* you're familiar with the various improvements on
27 > wear-leveling technique that have happened over the past *ten years*
28
29 yeah, I am. Or let it phrase it differently:
30 I know what is claimed.
31
32 The problem is, the best wear leveling does not help you if your disk is
33 pretty filled up and you still do a lot of writing. 1 000 000 write cycles
34 aren't much.
35
36 > since those concerns were first raised, I could probably raise an
37 > argument that a fresh SSD is likely to last longer as a swap device
38 > than as a filesystem.
39
40 depends - because thanks to wear leveling that 'swap partition' is just
41 something the firmware makes the kernel believe to be there.
42
43
44 >
45 > Swap is only touched as-needed, while there's been an explosion in
46 > programs and user software which demands synchronous writes to disk
47 > for data integrity purposes. (Firefox uses sqlite in such a way, for
48 > example; I discovered this when I was using sqlite heavily in my *own*
49 > application, and Firefox hung for a couple minutes during every batch
50 > insert.)
51
52 which is another goof reason not to use firefox - but
53 total used free shared buffers cached
54 Mem: 8182556 7373736 808820 0 56252 2197064
55 -/+ buffers/cache: 5120420 3062136
56 Swap: 23446848 82868 23363980
57
58 even with lots of ram, you will hit swap. And since you are using the wear-
59 leveling of the drive's firmware it does not matter that your swap resides on
60 its own partition - every page written means a block-rewrite somewhere. Really
61 not good for your ssd.
62
63 >
64 > Also, despite the MBTF data provided by the manufacturers, there's
65 > more empirical evidence that the drives expire faster than expected,
66 > anyway. I'm aware of this, and not particularly concerned about it.
67
68 well, it is your money to burn.
69
70 >
71 > >> Presumably, in scenarios where expanding the RAM in a system is
72 > >> prohibitively expensive, an SSD could reduce the impact of swap
73 > >> thrash.
74 > >
75 > > no, it is increasing the impact of SSD trash.
76 >
77 > False dichotomy. Yes, it increases the wear on the device. That says
78 > nothing of its impact on system performance, which was the nature of
79 > my point.
80
81 if you are so concerned of swap performance you should probably go with a
82 smaller ssd, get more ram and let that few mb of swap you need been handled by
83 several swap partitions.
84
85 >
86 > >> 2) While my system rarely goes above using 2-2.5GB of RAM, I enjoy
87 > >> having 6-8GB of RAM, just for the file cache. Of course, I lose that
88 > >> when I reboot; the cache needs to be repopulated. Has there been any
89 > >> work in the kernel for doing things like Vista/Win7's ReadyBoost?
90 > >> ReadyBoost has a ridiculous limit to only using 4GB of a flash drive,
91 > >> but I'd think that an 80GB SSD would be a massive performance
92 > >> improvement.
93 > >
94 > > with a SSD filecache is not that important anymore - and every usb-stick
95 > > is slower than a SSD.
96 >
97 > I'll poke the second argument first. I wouldn't use USB for something
98 > like this. USB2 is a painfully slow polling architecture. Something
99 > like this would need to be done with SATA. I'm *not* that daft.
100 >
101 > As for a filecache not being that important, that's only the case if
102 > your data of interest exists on the filesystem you put on the SSD.
103 >
104 > Let's say you're someone like me, who would tend to go with 60GB for /
105 > and 3TB for /home. At various times, I'll be doing HDR photo
106 > processing, some video transcoding, some random non-portage compile
107 > jobs, web browsing, coding, etc.
108
109 60gb for /, 75gb for /var, and 2.5tb data...
110 my current setup.
111
112 >
113 > If I take a 160GB SSD, I could put / (or, at least, /var/ and /usr),
114 > and have some space left over for scratch--but it's going to be a pain
115 > trying to figure out which of my 3TB of /home data I want in that fast
116 > scratch.
117 >
118 > File cache is great, because it takes caches your most-used data from
119 > *anywhere* and keeps it in a fast-access datastore. I could have a 3
120 > *petabyte* volume, not be particularly concerned about data
121 > distribution, and have just as response from the filecache as if I had
122 > a mere 30GB volume. Putting a filesystem on an SSD simply cannot scale
123 > that way.
124
125 true, but all those microseconds saved with swap on ssd won't offset the pain
126 when the ssd dies earlier.
127
128 >
129 > Actually, this conversation reminds me of another idea I'd had at one
130 > point...putting ext3/ext4's journal on an SSD, while keeping the bulk
131 > of the data on large, dense spinning platters.
132
133 which sounds nice in theory.
134
135 >
136 > >> Obviously, for something like Gentoo, putting an SSD-based filesystem
137 > >> under /var/tmp makes a lot of sense, but what other uses have been
138 > >> tried? How'd they work out?
139 > >
140 > > no, /var/tmp is very not important from a performance point of view -
141 > > with the exception of /var/tmp/portage - and that is a candidate for
142 > > tempfs.
143 > Did you miss the last week's worth of discussion of memory limits on tmpfs?
144
145 probably. Because I am using tempfs for /var/tmp/portage for ages and the only
146 problematic packet is openoffice/libreoffice.
147
148 --
149 #163933

Replies

Subject Author
Re: [gentoo-user] SSDs, swap, caching, other unusual uses Michael Mol <mikemol@×××××.com>