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 |