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