1 |
>> >> 2. added elevator=noop as a boot parameter |
2 |
>> > |
3 |
>> > I remember that I've given this second advice. Since then I've read in |
4 |
>> > the German computer journal c't [1] that CFQ has a detection for SSDs |
5 |
>> > since 2.6.28 and now is the best choice for these devices. |
6 |
>> |
7 |
>> OK, do I need a boot parameter if I've set CFQ as the default IO |
8 |
>> scheduler in the kernel config? |
9 |
> |
10 |
> No, that's what default switch is there for. |
11 |
> |
12 |
> |
13 |
>> > Yup, the entry should read: |
14 |
>> > tmp /tmp tmpfs default 0 0 |
15 |
> |
16 |
> I'd also suggest to explicitly specify max size of tmpfs mount, since |
17 |
> system locking because of wrong cp command is probably the last thing |
18 |
> you want. Argument is "size=" (see man 8 mount). |
19 |
> |
20 |
> |
21 |
>> Do you think mounting /tmp in RAM is worthwhile? Mike doesn't seem to |
22 |
>> think too highly of it. |
23 |
> |
24 |
> I guess accelerated fsync and reduced disk wear should be a nice plus |
25 |
> for SSD device, provided the path in question is constanly used for |
26 |
> writing which really might be the case with files, created in /tmp by |
27 |
> various mktemp implementations (like python's) which I haven't really |
28 |
> thought about, so I think I might be wrong about the issue here, sorry. |
29 |
|
30 |
Thanks guys. I think the /tmp trick made a good difference. The last |
31 |
thing I can think of is pruning the kernel way down. I think it's |
32 |
mostly default. |
33 |
|
34 |
- Grant |