1 |
On Fri, 12 Jun 2009 21:52:20 -0400 |
2 |
Joshua Murphy <poisonbl@×××××.com> wrote: |
3 |
|
4 |
> On Fri, Jun 12, 2009 at 5:52 PM, Maxim Wexler<maxim.wexler@×××××.com> wrote: |
5 |
> > On 6/12/09, Mike Kazantsev <mk.fraggod@×××××.com> wrote: |
6 |
> >> On Fri, 12 Jun 2009 13:45:04 -0600 |
7 |
> >> Maxim Wexler <maxim.wexler@×××××.com> wrote: |
8 |
> >> |
9 |
> >>> #shm /dev/shm tmpfs nodev,nosuid,noexec 0 0 |
10 |
> >> |
11 |
> >> I wonder, what's the rationale behind commenting out shm? |
12 |
> > |
13 |
> > Good question. I was given to understand the new line was intended to |
14 |
> > replaced the default, which I commented out. Perhaps that's a mistake. |
15 |
> > That's how I configured the previous iteration of genteee before it |
16 |
> > went south; maybe the new line had something to do with it. Should I |
17 |
> > use both? |
18 |
> |
19 |
> Hmm. |
20 |
> 1) a tmpfs space is, by default, mounted on /dev/shm to meet some |
21 |
> standard somewhere (can't recall, FHS I think). The important thing to |
22 |
> note is that the name 'shm' is basically an unused placeholder (tmpfs |
23 |
> doesn't operate on an actual block device like /dev/hda1), and that |
24 |
> /dev/shm is the mount *point*. It should be there, and uncommented. |
25 |
> |
26 |
... |
27 |
> |
28 |
> 3) Vaguely related to your mention of it 'taking its place' about the |
29 |
> /dev/shm and /tmp tmpfs mounts, the only time I've seen that mentioned |
30 |
> was in a conversation somewhere about 'why not just use a --bind mount |
31 |
> of /dev/shm onto /tmp to put it in tmpfs' ... which was answered with |
32 |
> the simple fact that, by default everywhere I've seen it, /dev/shm is |
33 |
> mounted noexec, while it's not altogether uncommon for things to be |
34 |
> decompressed into /tmp before execution (which would fail if /tmp were |
35 |
> mounted noexec). |
36 |
|
37 |
Indeed it should be there, it's as a shared memory for inter-process |
38 |
communication (IPC). Many stuff uses shared memory, notably gcc and |
39 |
multi-process daemons like apache, so you should give it to them. |
40 |
|
41 |
And, as noted, tmpfs is not real device or even some single virtual |
42 |
device. By "mount -t tmpfs none /tmp" you mount some piece of virtual |
43 |
memory to a place but it's never the same piece, so you can have two, |
44 |
ten or hundred tmpfs mounts completely independent of each other. |
45 |
|
46 |
mkdir /mnt/{tmp1,tmp2} |
47 |
mount -t tmpfs none /mnt/tmp1 |
48 |
mount -t tmpfs none /mnt/tmp2 |
49 |
touch /mnt/tmp1/some_file |
50 |
ls -la /mnt/tmp1 (shows "some_file" |
51 |
ls -la /mnt/tmp2 (empty) |
52 |
|
53 |
So you don't have to bind everything into one tmpfs, just create as |
54 |
many as you want, but, once again, especially if you chose not to have |
55 |
swap, limit their size so they won't eat all your RAM! |
56 |
Imagine scenario like this (or do "sync" and run it, but it should hang |
57 |
your machine!): |
58 |
|
59 |
mount -t tmpfs none /mnt/tmp1 |
60 |
dd if=/dev/zero of=/mnt/tmp1/some_file bs=1024 count=1000000000 |
61 |
|
62 |
Your VM should go away and kernel 'll go on a killing spree, wiping |
63 |
out all the runnuing processes, but, since tmpfs itself is not a |
64 |
process, it'll just kill everything until panic or nothing's left at |
65 |
all. |
66 |
"-o size=512M" will just give you "No free space on disk" instead of |
67 |
nasty crash. /tmp is world-writable, anything can choose to ditch a gig |
68 |
or two into it for whatever reasons... |
69 |
|
70 |
-- |
71 |
Mike Kazantsev // fraggod.net |